ISO/IEC 25059: ISO/IEC 25059 – Tutorial (about 60 minutes)

ISO/IEC 25059 is the international quality model for artificial intelligence (AI) systems. It takes the familiar software quality model of the SQuaRE family and extends it with the extra qualities that matter when a system learns from data, gives probabilistic answers and may change its behaviour after release – qualities such as robustness, transparency and the ability of people to step in. Product owners, data scientists, machine learning engineers, testers, risk and compliance staff, and buyers of AI products use it to describe what "good" means for an AI system before they build, test or accept it. After this tutorial you will be able to explain every addition the model makes, turn them into measurable requirements for a real AI system, and place the standard correctly next to ISO/IEC 25010, ISO/IEC 42001, ISO/IEC 23894 and related documents.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: The current published edition is ISO/IEC 25059:2023, the first edition, published in June 2023 by ISO and IEC. It was prepared by Joint Technical Committee ISO/IEC JTC 1, Subcommittee SC 42 (Artificial intelligence), working in liaison with SC 7 (Software and systems engineering), which owns the SQuaRE series. Its full title is "Software engineering – Systems and software Quality Requirements and Evaluation (SQuaRE) – Quality model for AI systems". The ISO catalogue marks the 2023 edition as "to be revised" (stage 90.92). A second edition, titled "Quality models for AI systems" (plural), is under development as ISO/IEC FDIS 25059: the final draft was registered for formal approval (stage 50.00) on 2026-07-23, and ISO states that it is expected to replace the 2023 edition within the coming months. Until that edition is published, ISO/IEC 25059:2023 is the edition in force, and it is the one taught here. The final text of the second edition is not public, so this course does not guess at its details; when it appears, check how it aligns with the 2023 revision of ISO/IEC 25010. Verified 2026-10-29 against the ISO catalogue entries for ISO/IEC 25059:2023 and ISO/IEC FDIS 25059 and the official preview of the 2023 edition (foreword, introduction, scope and contents).

A note on copyright: the standard is a short (15-page), paid, copyrighted document. This tutorial explains it in its own words and uses only the publicly known names of characteristics and sub-characteristics. Buy the standard if you need its exact definitions for a contract, a tender or an audit.

Who it is for: product managers and business analysts who write requirements for AI features, data scientists and ML engineers, software and test engineers, quality assurance staff, AI governance, risk and compliance teams, procurement teams that buy AI products, and auditors who need a shared vocabulary for AI quality.

Prerequisites: none. A basic idea of what machine learning is (a model trained on data that then makes predictions) will help. If you already know ISO/IEC 25010, you will move faster through Lesson 3.

Learning objectives. After this course you will be able to:

Explain why conventional software quality models are not enough for AI systems and what ISO/IEC 25059 adds.
Name the new and modified sub-characteristics of the product quality model and the quality-in-use model, and place each under its parent characteristic.
Distinguish closely related ideas such as user controllability and intervenability, or transparency in the product and transparency in use.
Turn the model into prioritised, measurable quality requirements and evaluation activities for a real AI system.
Explain how AI systems are evaluated against the model and why no certificate exists for ISO/IEC 25059 itself.
Relate the model to ISO/IEC 25010, 25012, the 5259 series, TS 25058, 42001, 23894 and 22989.

Lesson 1 – Origins, purpose and scope

Why AI needs its own quality model

Imagine two systems. The first is a payroll program: give it the same inputs and it will always produce the same payslip, and if the payslip is wrong, a developer can find the faulty line of code. The second is a model that predicts which customers are likely to cancel their contract. It was trained on last year's data, it gives a probability rather than a fixed answer, it is right for most customers but wrong for some, and its accuracy slowly drops as customer behaviour changes. Nobody can point to a single line of code that "causes" a wrong prediction.

Both are software, and both can be described with the classic software quality characteristics: they must be secure, reliable, maintainable and so on. But the second system raises questions the first never does. How correct is "correct enough" when perfection is impossible? What happens when the input data look different from the training data? Can a person override the prediction? Does anyone understand what the model was trained on and where it should not be used? Could its errors fall unfairly on one group of customers?

ISO/IEC 25059 exists to give these questions a home in a recognised quality model. Its introduction lists properties that set many AI systems apart: they can replace human decision-making, they can be built on noisy or incomplete data, they can be probabilistic, and they can adapt while they are in operation. Each of these properties creates new ways for a system to be "good" or "bad", and a quality model that ignores them leaves gaps in requirements, tests and acceptance decisions.

Where it comes from

The SQuaRE family (Systems and software Quality Requirements and Evaluation, ISO/IEC 25000 to 25099) has long provided the reference quality models for software. Its central model, ISO/IEC 25010:2011, described product quality with eight characteristics and quality in use with five. When ISO and IEC set up SC 42 to standardise artificial intelligence, SQuaRE experts had already been asking at their own workshops which quality attributes the existing models missed for data-driven, learning systems. ISO/IEC 25059 is the result: a project approved in May 2020, developed by SC 42's working group on trustworthiness (WG 3) in liaison with the SC 7 experts who maintain SQuaRE, and published in June 2023.

What kind of document it is

The scope describes the document as an application-specific extension to SQuaRE. That phrase is the key to understanding it. ISO/IEC 25059 does not replace ISO/IEC 25010 and does not repeat it. It takes the 25010 model as its foundation (the 2023 edition cites ISO/IEC 25010:2011 as a normative reference) and adds or modifies only what AI needs. Everything in the base model still applies to an AI system; the extension sits on top.

The scope gives the model two jobs. First, it offers consistent terminology for specifying, measuring and evaluating the quality of AI systems, so that a buyer, a supplier and a tester mean the same thing by "robustness". Second, it acts as a checklist: you can compare a set of stated quality requirements against the model to see whether anything important has been forgotten.

What it does not do

It sets no target values. It never says that a model must be 95 % accurate; the right level depends on the task and the risk.
It contains no requirements for an organisation or its management system, so there is nothing for a certification body to audit.
It does not define the measures or the evaluation process. Those come from other SQuaRE documents and from AI-specific guidance (see Lessons 4 and 5).
It does not model data quality; data quality has its own models in ISO/IEC 25012 and the ISO/IEC 5259 series.
It is not an ethics code or a law, although its characteristics help express what laws and ethics frameworks ask for.

The two other normative references tell you where the AI vocabulary comes from: ISO/IEC 22989:2022 (AI concepts and terminology) and ISO/IEC 23053:2022 (a framework for AI systems that use machine learning). Terms such as "AI system", "model", "training" and "task" are taken from those documents rather than redefined.

Lesson 2 – Key concepts and vocabulary

The definitions below are paraphrased in plain words. They are close enough to use in everyday work, but the standard's own wording is what counts in a contract.

AI system – an engineered system that produces outputs such as content, forecasts, recommendations or decisions for a given set of human-defined objectives (the concept comes from ISO/IEC 22989).
Quality model – a defined set of characteristics, and the relationships between them, that gives a framework for specifying quality requirements and evaluating quality.
Characteristic and sub-characteristic – a characteristic is a broad quality category (for example reliability); a sub-characteristic is a narrower, more measurable part of it (for example robustness).
Product quality – the degree to which the system itself satisfies stated and implied needs, as a property of the product that can be built in and tested.
Quality in use – the degree to which the system lets specific users meet their needs in a specific context of use: the outcome when real people use it for real work.
Task – what the AI system is meant to do, such as classifying images or ranking candidates. One system can have several tasks, and quality requirements can be set for how well each task is fulfilled.
Functional correctness (modified for AI) – how far the system gives correct results with the precision that is needed. For machine learning it is accepted that results will not be correct in every case, so correctness is described statistically.
Functional adaptability – how well an AI system can take in information from data, or from the results of its own earlier actions, and use it accurately in later predictions; in short, how well it learns during operation.
User controllability – how well a user can step into the operation of an AI system in an appropriate way and at the right time, for example to correct, pause or redirect it.
Transparency (product) – how well appropriate information about the AI system – its purpose, abilities, limitations, data and workings – is passed to the stakeholders who need it.
Robustness – how well an AI system keeps its level of performance across all circumstances, including noisy, unusual or deliberately manipulated inputs.
Intervenability – how well an operator can intervene in the functioning of an AI system quickly enough to prevent harm or hazard.
Societal and ethical risk mitigation – a quality-in-use sub-characteristic: how well the system, in use, limits risks to society, such as unfair treatment of groups or harm to fundamental rights.
Transparency (in use) – a quality-in-use sub-characteristic under satisfaction: how far the people who use the system feel adequately informed about it in their actual work.
Measure – a variable that gets a value as the result of measurement, such as a false-negative rate or the time needed to stop an automated process.

Two words that are easy to confuse

Transparency and explainability are related but not the same. Transparency is about information being available to stakeholders: what the system is for, what data it was trained on, what its known limits are, when it was last updated. Explainability is about being able to give understandable reasons for a particular output. A system can be transparent (well documented, honestly described) while still producing individual decisions that are hard to explain. ISO/IEC 25059:2023 adds transparency; explainability is treated in other SC 42 work.

The second pair is user controllability and intervenability. Both are about people stepping in, but they answer different questions. User controllability belongs to usability: can the person using the system steer it appropriately in normal work – accept, reject, adjust or undo a suggestion? Intervenability belongs to security: can an operator stop or override the system in time when something is going wrong, so that damage or danger is avoided? A chatbot that lets you regenerate an answer shows user controllability; a factory robot with an emergency stop that halts its AI-driven motion shows intervenability.

Product view and use view

Like SQuaRE in general, ISO/IEC 25059 looks at quality from two sides. The product view looks inward at properties the developers can design and test. The use view looks outward at what happens when people use the system in a real context. Good product quality makes good quality in use more likely, but it cannot guarantee it: a well-tested model can still cause harm if it is used for a purpose or a population it was never designed for.

Lesson 3 – Structure of the standard and the extended model

How the document is organised

The 2023 edition is compact. After the usual foreword and introduction, it follows the standard ISO layout:

Clause 1 – Scope: an application-specific SQuaRE extension for AI systems.
Clause 2 – Normative references: ISO/IEC 25010:2011, ISO/IEC 22989:2022 and ISO/IEC 23053:2022.
Clause 3 – Terms and definitions: general terms, product quality terms and quality-in-use terms.
Clause 4 – Abbreviated terms.
Clause 5 – Product quality model: a general part, then one sub-clause for each added or modified sub-characteristic.
Clause 6 – Quality in use model: a general part, then sub-clauses for the two additions.
Annex A (informative) – an overview of the SQuaRE series.
Annex B (informative) – how a risk-based approach relates to a quality-based approach and to quality models.
Annex C (informative) – a discussion of "performance" as the word is used for AI systems.

Because the extension depends on its base, it helps to see where it sits in SQuaRE. The family is organised into divisions: quality management (2500n), quality models (2501n), quality measurement (2502n), quality requirements (2503n) and quality evaluation (2504n). The numbers 25050 to 25099 are reserved for the extension division: documents that apply SQuaRE to a particular kind of product or domain. ISO/IEC 25059 is one of these extensions. Its number puts it in the extension range, while its content builds directly on the quality model ISO/IEC 25010.

Figure 1 – ISO/IEC 25059 is a SQuaRE extension that builds on the ISO/IEC 25010 quality model, and TS 25058 guides evaluation against it.

The product quality model for AI

The base product model of ISO/IEC 25010:2011 has eight characteristics: functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability and portability. ISO/IEC 25059 keeps all eight. It changes four of them by adding six sub-characteristics and modifying one existing sub-characteristic:

Characteristic (from ISO/IEC 25010:2011)	Change in ISO/IEC 25059:2023	What it means for AI, in plain words
Functional suitability	Functional correctness – modified	Results will sometimes be wrong; specify and measure how often, how badly and for whom.
Functional suitability	Functional adaptability – added	If the system learns from new data or feedback, it should learn accurately and actually improve.
Usability	User controllability – added	Users can steer, correct or undo what the system does, at the right moment.
Usability	Transparency – added	Stakeholders get the information they need about purpose, abilities, limits and data.
Reliability	Robustness – added	Performance holds up under noise, unusual inputs, changed conditions and attacks.
Security	Intervenability – added	An operator can stop or override the system in time to prevent harm.

The other four characteristics – performance efficiency, compatibility, maintainability and portability – are not changed, but they still apply. An AI system must still answer quickly enough, work with neighbouring systems, be maintainable (including retraining pipelines) and move between environments.

Figure 2 – In the product model, four of the eight ISO/IEC 25010 characteristics gain AI-specific sub-characteristics, and functional correctness is redefined.

Why each addition sits where it does

Functional correctness was modified rather than added because it already existed. In conventional software, an incorrect result is a defect to be removed. In machine learning, some incorrect results are a normal and expected property of the approach, so the standard notes that correctness cannot be assumed in all observed circumstances and has to be measured carefully – for example as an error rate on representative data.

Functional adaptability also belongs to functional suitability, because learning in operation changes what the system does. It is different from the base model's "adaptability" sub-characteristic under portability, which is about moving software to new hardware or environments. The similar names are a common trap.

User controllability and transparency belong to usability because both shape how effectively a person can work with the system. A user who cannot see the system's limits, or cannot correct it, will either trust it too much or abandon it.

Robustness belongs to reliability because it is about keeping performance stable over a range of conditions. It complements the existing reliability sub-characteristics (maturity, availability, fault tolerance, recoverability), which mostly concern faults and outages rather than unusual data.

Intervenability belongs to security because it protects people and assets: the ability of an operator to take control is a safeguard against the system causing harm, whether through malfunction, misuse or attack.

The quality-in-use model for AI

The base quality-in-use model in ISO/IEC 25010:2011 has five characteristics: effectiveness, efficiency, satisfaction, freedom from risk and context coverage. ISO/IEC 25059 keeps all five and adds two sub-characteristics:

Under freedom from risk, which already covered economic, health and safety, and environmental risk mitigation, it adds societal and ethical risk mitigation. This recognises that AI systems in use can harm society – for example by discriminating against a group, spreading misinformation or undermining privacy and autonomy – even when they work exactly as designed.
Under satisfaction, which already covered usefulness, trust, pleasure and comfort, it adds transparency. Here the focus is the user's experience: do the people relying on the system feel they know enough about it to use it with confidence?

Figure 3 – In the quality-in-use model, satisfaction gains transparency and freedom from risk gains societal and ethical risk mitigation.

The informative annexes

Annex B is worth reading even though it is informative. Many AI frameworks are risk-based: they start from what could go wrong (ISO/IEC 23894, ISO 31000, the NIST AI Risk Management Framework). A quality model is quality-based: it starts from the properties the system should have. The annex explains that the two approaches are complementary. Risk analysis helps decide which quality characteristics matter most and how strict the targets must be; the quality model gives the vocabulary to write those targets as requirements and to check them. Annex C is a short informative note on performance as the term applies to AI systems. Whatever its exact wording, the practical lesson is that the word is used in two ways: in AI conversations "performance" usually means how well a model does its task (accuracy and similar measures), whereas in SQuaRE "performance efficiency" means speed and resource use. Keeping the two meanings apart in your own requirements avoids confusion.

A note on newer names

ISO/IEC 25010 was itself revised in 2023. That edition renamed usability to "interaction capability" and portability to "flexibility", moved the quality-in-use model to a separate standard (ISO/IEC 25019) and made other changes. ISO/IEC 25059:2023 was written against the 2011 base, so it uses the older names. Some secondary sources already map the AI additions onto the new names (for example, placing user controllability and transparency under interaction capability). This is a reasonable reading, but until the second edition of ISO/IEC 25059 is published, the official text refers to the 2011 structure.

Lesson 4 – How it works in practice

ISO/IEC 25059 is a model, not a method, so on its own it tells you what to think about, not how to run a project. In practice teams combine it with the SQuaRE requirements and evaluation standards and with their normal delivery lifecycle. The steps below are a common pattern.

Step 1 – Describe the system, its tasks and its context

Start by writing down what the AI system is for: its tasks, its users, the decisions it influences, the data it uses and the environment it runs in. Note whether it learns in operation, whether it acts automatically or only advises a person, and who could be affected by its outputs, including people who never use it directly. This description is the anchor for every later decision; quality is always quality for a purpose.

Step 2 – Analyse risks and stakeholder needs

Use a risk process (for example ISO/IEC 23894) and stakeholder interviews to find out what could go wrong and what matters most. A recommendation engine for films and a model that prioritises emergency calls both use machine learning, but the consequences of errors are worlds apart. The risk picture tells you which characteristics need strict requirements and which only need a sanity check.

Step 3 – Walk the model and select characteristics

Go through every characteristic of both models – the eight base product characteristics with their AI additions, and the five quality-in-use characteristics with theirs – and decide for each whether it is relevant, how important it is, and why. Recording "not relevant because…" is useful too: it shows the decision was made rather than forgotten. This is the completeness check that the scope of the standard promises.

Step 4 – Write measurable quality requirements

Turn each selected sub-characteristic into a requirement with a measure, a target, a condition and a method of verification. ISO/IEC 25030 gives general guidance on quality requirements. Examples:

Functional correctness: on a held-out test set that reflects the production population, recall for the "high risk" class is at least the agreed level, reported separately for each customer segment.
Robustness: when 10 % of input fields are missing or corrupted, accuracy falls by no more than an agreed number of percentage points; the system flags low-confidence cases instead of guessing.
User controllability: a reviewer can override any recommendation in one step and the override is recorded with a reason.
Intervenability: an authorised operator can switch the system to a safe fallback mode within an agreed number of minutes, and this is tested in each release.
Transparency: a current model description (purpose, training data period, known limits, version, owner) is published to users and updated with each retraining.
Functional adaptability: after each retraining, performance on a fixed benchmark must not drop below the previous version; otherwise the update is rolled back.
Societal and ethical risk mitigation: differences in error rates between protected groups stay within an agreed tolerance, reviewed quarterly in production.

The numbers in such requirements are your choice. The standard deliberately leaves them open, because a target that is reasonable for one task can be dangerous or wasteful for another.

Step 5 – Choose measures and evaluation methods

Each requirement needs a way to be checked. The SQuaRE measurement division (for example ISO/IEC 25023 for product quality measures and ISO/IEC 25022 for quality in use) supplies general measures, while AI-specific measures come from machine learning practice: confusion-matrix rates, calibration, performance on perturbed or adversarial inputs, drift indicators, time-to-intervene in drills, user-research results on understanding and trust. ISO/IEC TS 25058 gives guidance on evaluating AI systems with the quality model, and the ISO/IEC 24029 series covers the assessment of neural network robustness.

Step 6 – Build quality in, evaluate and decide

Design and engineering choices follow from the requirements: data selection and labelling, model choice, guardrails, confidence thresholds, human review steps, override buttons, emergency stops, documentation. Before release, the system is evaluated against the requirements – ideally by people who did not build it – and an explicit acceptance decision is recorded.

Step 7 – Monitor in operation and feed back

For AI systems, evaluation does not end at release. Data drift, changing user behaviour and retraining can all change quality after go-live. Production monitoring should track the same measures used before release, and the results should feed back into the requirements and risk analysis. The quality-in-use characteristics in particular can only be judged properly in real use.

Figure 4 – A typical lifecycle for applying ISO/IEC 25059, in which monitoring in operation feeds back into risk analysis and requirements.

Roles and artefacts

No roles are prescribed, but a typical split looks like this. The product owner or business analyst leads steps 1, 3 and 4 with stakeholders. Data scientists and ML engineers propose feasible targets and measures and build quality in. Testers or an independent evaluation team design and run the evaluation. Risk and compliance staff link the requirements to the risk register and to legal obligations. Operations teams own monitoring and intervention procedures. Typical artefacts are a system description, a quality requirements specification structured by the model, an evaluation plan and report, model and data documentation, and a monitoring dashboard with the agreed measures.

Lesson 5 – Assessment, certification and compliance

Is there an ISO/IEC 25059 certificate?

No. ISO/IEC 25059 contains no requirements for an organisation, so there is no management-system certification against it in the way that organisations are certified to ISO 9001 or ISO/IEC 42001. It is also not a product specification with pass/fail thresholds. Be cautious with any claim such as "ISO/IEC 25059 certified AI": the honest form of such a claim is that a particular AI system was evaluated against requirements derived from the ISO/IEC 25059 model, by a named evaluator, using a stated method, with stated results.

How AI systems are evaluated against the model

Evaluation is about a specific system, a specific version and specific requirements. The general SQuaRE evaluation process (ISO/IEC 25040) runs through establishing the evaluation requirements, specifying the evaluation, designing it, executing it and concluding it. ISO/IEC TS 25058, published in 2024 by SC 42, gives AI-specific guidance on carrying out such evaluations with the AI quality model. The evaluation can be done at three levels of independence:

First party – the developer evaluates its own system as part of testing and release.
Second party – a customer or acquirer evaluates a supplier's system, often as part of procurement or acceptance testing.
Third party – an independent laboratory or assessment body evaluates the system, which may be required for high-stakes uses or requested to build trust.

What evidence looks like

Good evidence is specific and repeatable: test data descriptions and how they represent the production population; correctness results broken down by segment and with confidence intervals; robustness test results under defined perturbations; logs of override and emergency-stop drills; user-research findings on how well people understood and controlled the system; documentation actually delivered to users; and monitoring data from production. A table that maps each sub-characteristic to its requirement, measure, result and verdict makes the evaluation easy to review.

Compliance and regulation

No law makes ISO/IEC 25059 mandatory in general, but its vocabulary maps well onto regulatory expectations. The EU AI Act, for example, asks providers of high-risk AI systems for appropriate accuracy, robustness and cybersecurity (Article 15), transparency and information to deployers (Article 13) and human oversight (Article 14). The quality model gives teams a structured way to express and evidence those properties: correctness and robustness for accuracy and resilience, transparency for information duties, user controllability and intervenability for human oversight. The model is a tool for showing how requirements were met; it is not itself proof of legal compliance, and harmonised standards under the Act are a separate matter to check for your use case.

Inside organisations, the model is often used together with an AI management system. ISO/IEC 42001 requires an organisation to manage AI responsibly and to set objectives and controls; ISO/IEC 25059 helps to turn the product-level parts of those objectives into concrete, testable quality requirements for each AI system.

Lesson 6 – Worked example: a claims triage assistant

The situation

NorthBay Insurance, a mid-sized motor and home insurer, wants a machine learning assistant to triage incoming claims. For each new claim the assistant gives a score for how likely the claim needs a detailed investigation (for example possible fraud or complex damage) and a short list of the factors that drove the score. Claims handlers see the score and decide whether to fast-track the payment or send the claim to the investigation team. The model will be retrained every month with the outcomes of closed claims. The product owner, Leila, decides to use ISO/IEC 25059 to structure the quality requirements before a supplier is selected.

Step 1 and 2 – Context and risks

Leila's team describes the task (rank claims by need for investigation), the users (around 120 claims handlers), the people affected (policyholders, who never see the model) and the data (claim forms, policy history, photographs, repair estimates). A risk workshop finds four main concerns: genuine customers being delayed by wrongly flagged claims; fraud slipping through; unfair treatment of customers in certain postcodes or with certain names, which could act as proxies for ethnicity; and handlers rubber-stamping the score without thinking. Because the assistant only advises and a person decides, the harm from a single error is limited, but the scale (tens of thousands of claims a year) makes systematic errors serious.

Step 3 – Walking the model

The team goes through every characteristic. Performance efficiency matters (a score within two seconds of claim submission); compatibility matters (integration with the claims platform); maintainability matters a lot (a monthly retraining pipeline must be easy to change and test). Portability is low priority because the system runs on a single cloud platform. Then they focus on the AI additions:

Functional correctness – high priority. Missing fraud and delaying honest customers are both costly, so they specify both the share of flagged claims that really needed investigation and the share of investigation-worthy claims that were flagged.
Functional adaptability – high priority, because the model learns monthly. Each new version must beat or equal the current one on a frozen benchmark set before it goes live.
User controllability – high priority. Handlers must be able to override the score in one click, give a reason, and see that overrides are respected. The interface must not hide the "fast-track" option for high scores.
Transparency (product) – medium-high. Handlers get a one-page description of the model: what it predicts, what data it uses, what it cannot see (for example, phone calls), its known weak spots and its current version.
Robustness – high. Claim forms are often incomplete, photographs vary in quality, and fraudsters adapt. The model must degrade gracefully and flag low-confidence cases.
Intervenability – medium-high. Operations must be able to switch the assistant off for the whole company within 15 minutes, with handlers falling back to the old rules-based checklist.
Societal and ethical risk mitigation – high. Postcode and name must not drive unfair differences in flagging rates between groups.
Transparency (in use) – medium. Handlers should report that they understand the score well enough to explain their decision to a customer.

Step 4 – Requirements

The team writes 22 quality requirements. Three of them illustrate the style. QR-07 (robustness): "With up to three optional claim fields missing, the share of investigation-worthy claims that are flagged falls by no more than 3 percentage points against complete claims on the benchmark set; claims with confidence below the agreed threshold are marked 'needs human review' instead of receiving a score." QR-12 (intervenability): "An on-call operations manager can disable scoring for all users within 15 minutes; tested in a drill before go-live and every quarter." QR-18 (societal and ethical risk mitigation): "Flagging rates for claims grouped by region and by inferred demographic group are compared monthly; any gap above the agreed tolerance triggers a review before the next model release."

Step 5 and 6 – Evaluation

The insurer's own test team, independent of the supplier, runs the acceptance evaluation following the general SQuaRE evaluation process and the guidance in ISO/IEC TS 25058. They build a benchmark set from two years of closed claims, add a perturbed version with missing fields and blurred photographs, and run a fairness analysis. They also run an intervention drill and a two-week pilot with 15 handlers. The results are mixed: correctness and robustness meet the targets, the drill switches the system off in nine minutes, but the pilot shows that handlers override fewer than 1 % of scores, and interviews reveal that many assumed the model "knew more" than it did. The user-side transparency and controllability goals are therefore not met in practice, even though the override button works perfectly.

Step 7 – Fixes and monitoring

The team changes the interface to show the main factors next to each score and a plain warning when the claim type is rare in the training data, adds short training on the model's limits, and adds an indicator of override rates to the operations dashboard. A second pilot shows healthier behaviour: handlers question the score when it conflicts with what they know. After go-live, monthly monitoring tracks correctness by segment, drift in input data, group-level flagging rates, override rates and retraining results. Three months later, drift alerts reveal that a new online claim form changed how damage descriptions are entered; the retraining gate catches a drop in performance and the update is held back until the data pipeline is fixed.

What the example shows

The model did not tell NorthBay what targets to set or which tools to use. What it did was make sure nothing important was forgotten, give the team and the supplier a shared language, and separate properties of the product (an override button exists and works) from outcomes in use (people actually use it sensibly). That separation is exactly why ISO/IEC 25059 keeps both the product view and the use view.

Lesson 7 – Relationship to other standards and frameworks

ISO/IEC 25059 is a small piece in a large and growing puzzle of AI and software standards. Knowing its neighbours helps you use each one for what it does best.

Standard or framework	What it covers	Relationship to ISO/IEC 25059
ISO/IEC 25010 (2011; revised 2023)	General product quality model for software and ICT products (the 2011 edition also held the quality-in-use model, now ISO/IEC 25019)	The base that ISO/IEC 25059 extends; all of its characteristics still apply to AI systems.
ISO/IEC 25012 and ISO/IEC 5259 series	Data quality model, and data quality for analytics and machine learning	Complementary: they cover the quality of the data, ISO/IEC 25059 covers the quality of the AI system.
ISO/IEC TS 25058:2024 (marked "to be revised")	Guidance for the quality evaluation of AI systems	Explains how to evaluate systems using the quality model that ISO/IEC 25059 defines.
ISO/IEC 25040 and 2502n measures	General evaluation process and quality measures	Provide the process and many of the measures used in an evaluation.
ISO/IEC 42001:2023	Certifiable AI management system for organisations	Organisation level; ISO/IEC 25059 helps express system-level quality objectives and requirements.
ISO/IEC 23894:2023	Guidance on AI risk management	Risk-based view; risk analysis sets priorities and targets for the quality characteristics.
ISO/IEC 22989 and ISO/IEC 23053	AI concepts and terminology; framework for ML-based AI systems	Normative references that supply the AI vocabulary used in the model.
NIST AI Risk Management Framework	Voluntary US framework describing characteristics of trustworthy AI and risk functions	Overlapping ideas (validity and reliability, safety, resilience, transparency, fairness) expressed as a risk framework rather than a quality model.

Quality, risk and management: three layers

A helpful way to keep these documents apart is to think in layers. At the top, an AI management system (ISO/IEC 42001) governs how an organisation develops, provides or uses AI – policies, roles, objectives, impact assessments, continual improvement. In the middle, risk management (ISO/IEC 23894) identifies and treats the risks of particular AI systems. At the system level, the quality model (ISO/IEC 25059) names the properties each system must have, and the evaluation guidance (ISO/IEC TS 25058 with ISO/IEC 25040) checks whether it has them. Data quality standards (ISO/IEC 25012 and 5259) look after the raw material underneath.

Figure 5 – Management, risk, quality and evaluation standards work as layers: risk sets priorities, the quality model names the properties, and evaluation checks them.

Trustworthiness

Many AI documents speak of trustworthiness, a broad idea covering reliability, safety, security, privacy, fairness, transparency, accountability and more. ISO/IEC 25059 does not try to define trustworthiness as a whole. Instead it supplies some of its measurable building blocks inside a proven quality structure. When a policy says "our AI must be trustworthy", the quality model helps break that sentence down into requirements that someone can test.

Common pitfalls and best practices

Common pitfalls

Treating accuracy as the whole of quality. A high headline accuracy says nothing about robustness, fairness, controllability or transparency, and it can hide very poor results for small groups.
Forgetting the base model. Teams fascinated by the AI additions sometimes skip ordinary characteristics such as security, maintainability or performance efficiency, which still cause many real failures.
Confusing similar terms. Mixing up functional adaptability (learning in operation) with the portability sense of adaptability, or user controllability with intervenability, leads to the wrong requirements and tests.
Testing only at release. AI quality changes with drift and retraining; a one-off acceptance test gives false comfort.
Claiming certification. Advertising a system as "ISO/IEC 25059 certified" misrepresents a model that has no certification scheme and no pass marks.
Copying targets from elsewhere. A threshold that suited another task or organisation may be meaningless or unsafe for yours.
Assuming a working control means control in use. An override that exists but is never used, or an explanation nobody reads, meets the product requirement but fails the quality-in-use goal.

Best practices

Walk the whole model every time. Record a decision and a reason for every characteristic, including those you judge irrelevant.
Let risk drive strictness. Use a risk assessment to decide which sub-characteristics need tight targets and independent evaluation.
Measure by segment. Report correctness and robustness for relevant groups and conditions, not only as a single average.
Test human control for real. Run intervention drills and user studies, and watch override rates in production.
Gate every retraining. Compare each new model with the current one on a fixed benchmark and roll back if quality drops.
Keep documentation alive. Update the system description, limits and version information with each change, and check that users actually receive it.
Pair it with management and data standards. Use ISO/IEC 42001 for governance and ISO/IEC 25012 or the 5259 series for data, so that the quality model is not carrying jobs it was not designed for.

Summary and key takeaways

ISO/IEC 25059:2023 is an application-specific extension of the SQuaRE quality model for AI systems; it builds on ISO/IEC 25010 rather than replacing it, and a second edition is at the final draft stage.
In the product model it modifies functional correctness and adds functional adaptability, user controllability, transparency, robustness and intervenability under four existing characteristics.
In the quality-in-use model it adds societal and ethical risk mitigation under freedom from risk and transparency under satisfaction.
The model gives shared terminology and a completeness checklist; it sets no targets and has no organisational requirements.
Requirements become useful only when each one has a measure, a target, conditions and a verification method chosen for the specific task and risk.
Evaluation follows SQuaRE processes with AI-specific guidance in ISO/IEC TS 25058, and it must continue in operation because AI quality drifts.
There is no ISO/IEC 25059 certificate; honest claims name the system, the evaluator, the method and the results.
The model works best alongside ISO/IEC 42001 (management), ISO/IEC 23894 (risk) and ISO/IEC 25012 and 5259 (data).

Reflection questions

Pick an AI feature you use or build. Which of the six product additions would you rank highest for it, and what evidence would convince you that it is good enough?
Describe a situation in your work where a user would need controllability but an operator would need intervenability. How would you test each one?
How would you set a correctness target for a model whose errors have very different costs in each direction (missing a case versus raising a false alarm)?
Your supplier advertises an "ISO/IEC 25059 certified" AI product. What questions would you ask to understand what was actually evaluated?
Which societal or ethical risks could your chosen AI system create in use, even when it performs exactly as designed, and how would you monitor them after release?