Question 1

What does ISO/IEC 23053 provide for describing an AI system built on machine learning?

Accepted Answer

ISO/IEC 23053:2022 establishes a framework in which a generic AI system built on machine-learning technology is described through its components and their functions; the standard is addressed to organizations of every type and size, public and private. Prepared by ISO/IEC JTC 1, Subcommittee SC 42 (Artificial intelligence), the standard describes the machine-learning system through its task, model, data and tools (Clause 6) and catalogues the machine-learning approaches in use: supervised, unsupervised, semi-supervised, self-supervised, reinforcement and transfer learning (Clause 7). Clause 8 sets out the machine-learning pipeline. The vocabulary of Clause 3 covers model development and use (classification model, regression model, generalization, overfitting, underfitting), tools (backpropagation, learning rate) and data concepts (class, cluster, feature, distance). Its single normative reference is ISO/IEC 22989, the terminology standard whose definitions it adopts. The introduction records the document's purpose: to supply shared terminology and concepts through which AI systems that learn from data can be explained to expert and non-expert audiences alike, and to serve as a point of departure for further standards that address particular aspects of machine-learning systems and their components. Wording here is paraphrased from the ISO text as previewed on the ISO Online Browsing Platform; the full standard is available from ISO.

Question 2

What level of accuracy, robustness and cybersecurity does Article 15 require of high-risk AI systems?

Accepted Answer

Article 15(1) provides: "High-risk AI systems shall be designed and developed in such a way that they achieve an appropriate level of accuracy, robustness, and cybersecurity, and that they perform consistently in those respects throughout their lifecycle." The obligation attaches at design and development time, not after release. Article 15(2) directs the European Commission, in cooperation with relevant stakeholders and organisations such as metrology and benchmarking authorities, to encourage, as appropriate, the development of benchmarks and measurement methodologies for measuring the appropriate levels of accuracy and robustness and any other relevant performance metrics. Article 15(3) then converts achieved accuracy into a declared figure: "The levels of accuracy and the relevant accuracy metrics of high-risk AI systems shall be declared in the accompanying instructions of use." Article 15 sits in Chapter III, Section 2 of Regulation (EU) 2024/1689 — the requirements a high-risk AI system must satisfy — and the metrics used to measure accuracy and robustness are recorded in the technical documentation under Annex IV, point 2(g). Under Article 113 of Regulation (EU) 2024/1689, as amended by Regulation (EU) 2026/1744, the Chapter III, Section 2 requirements apply from 2 December 2027 to systems that are high-risk under Article 6(2) and Annex III, and from 2 August 2028 to systems that are high-risk under Article 6(1) and Annex I; the full application timeline is set out at the end of this page.

Question 3

How must a high-risk AI system withstand errors, faults and feedback loops under Article 15(4)?

Accepted Answer

Article 15(4) requires high-risk AI systems to be "as resilient as possible regarding errors, faults or inconsistencies that may occur within the system or the environment in which the system operates", in particular due to their interaction with natural persons or other systems, with technical and organisational measures taken in this regard. The provision states that robustness may be achieved through technical redundancy solutions, which may include backup or fail-safe plans. Its third subparagraph addresses systems whose training continues after release: "High-risk AI systems that continue to learn after being placed on the market or put into service shall be developed in such a way as to eliminate or reduce as far as possible the risk of possibly biased outputs influencing input for future operations (feedback loops), and as to ensure that any such feedback loops are duly addressed with appropriate mitigation measures." The parenthetical term "feedback loops" is the regulation's own. For the design stage this means the training arrangement itself — including any continuous-learning mechanism that feeds system outputs back into future inputs — is a regulated design feature of the system, not an operational afterthought. Under Article 113 of Regulation (EU) 2024/1689, as amended by Regulation (EU) 2026/1744, Article 15(4) applies from 2 December 2027 to systems that are high-risk under Article 6(2) and Annex III, and from 2 August 2028 to systems that are high-risk under Article 6(1) and Annex I; the full application timeline is set out at the end of this page.

Question 4

What resistance to attack does Article 15(5) require of a high-risk AI system?

Accepted Answer

Article 15(5) provides that high-risk AI systems "shall be resilient against attempts by unauthorised third parties to alter their use, outputs or performance by exploiting system vulnerabilities", with technical solutions appropriate to the relevant circumstances and the risks. The provision names the attack classes specific to machine learning. Technical solutions addressing AI-specific vulnerabilities shall include, where appropriate, "measures to prevent, detect, respond to, resolve and control for attacks trying to manipulate the training data set (data poisoning), or pre-trained components used in training (model poisoning), inputs designed to cause the AI model to make a mistake (adversarial examples or model evasion), confidentiality attacks or model flaws." Two of the enumerated attacks operate on the training stage itself: data poisoning targets the training data set before or during training, and model poisoning targets pre-trained components incorporated into training — which places third-party pre-trained models and datasets inside the security perimeter the provider must address at design time. Article 15(5) forms part of Chapter III, Section 2 and, under Article 113 of Regulation (EU) 2024/1689, as amended by Regulation (EU) 2026/1744, applies from 2 December 2027 to systems that are high-risk under Article 6(2) and Annex III and from 2 August 2028 to systems that are high-risk under Article 6(1) and Annex I; the full application timeline is set out at the end of this page.

Question 5

What is the transformer architecture?

Accepted Answer

The transformer is a neural-network architecture introduced by Vaswani, Shazeer, Parmar, Uszkoreit, Jones, Gomez, Kaiser and Polosukhin in 2017; it relies entirely on attention mechanisms, removing the recurrent and convolutional components of earlier sequence-transduction models. The paper, "Attention Is All You Need", proposed the architecture for machine translation and reported that the models were more parallelizable and required significantly less training time than the recurrent and convolutional encoder-decoder models then in use; the reported English-to-French result was trained for three and a half days on eight GPUs, a small fraction of the training costs reported for prior models. The paper also reported that the architecture generalized to other tasks, demonstrated on English constituency parsing. The transformer is the object of the training-compute literature covered on this page: Hoffmann et al. (2022) frame their study as finding the optimal model size and number of training tokens for a transformer language model. Under the EU AI Act, architecture is a documented fact of record — providers of general-purpose AI models must record "the architecture and number of parameters" in the Annex XI technical documentation. The paper's findings are displayed here as reported by its authors.

Question 6

What do the scaling-law studies report about compute, data and model size?

Accepted Answer

Kaplan et al. (2020) report that language-model loss falls as a power law in model size, dataset size and training compute, with some trends spanning more than seven orders of magnitude; Hoffmann et al. (2022) report that, for compute-optimal training under a fixed budget, model size and the number of training tokens scale in equal proportion. Kaplan et al. studied empirical scaling of cross-entropy loss and reported that, within wide ranges, architectural details such as network width or depth have minimal effect; that larger models are significantly more sample-efficient; and that compute-efficient training on their account involves very large models trained on comparatively modest data and stopped well before convergence. Hoffmann et al. revisited the allocation question by training over 400 language models from 70 million to over 16 billion parameters on 5 to 500 billion tokens, concluding that for compute-optimal training every doubling of model size should be matched by a doubling of training tokens — a finding that implied contemporary large models were significantly undertrained. They tested the prediction with Chinchilla, a 70-billion-parameter model trained on around four times more data than the 280-billion-parameter Gopher at the same compute budget; the paper reports Chinchilla outperformed Gopher, GPT-3 (175B), Jurassic-1 (178B) and Megatron-Turing NLG (530B) on a large range of downstream evaluations, with substantially less compute needed for fine-tuning and inference. Both sets of findings are displayed as the papers report them.

Question 7

How is training compute documented across the public model record?

Accepted Answer

Epoch AI's Data on AI Models database tracks over 3,500 models, recording training compute in floating-point operations (FLOP) alongside parameter counts, training dataset size, training time, power draw and cost; the data are released under the Creative Commons Attribution licence. Epoch AI's documentation states that models are collected from literature reviews, Papers With Code, historical accounts, highly cited publications, proceedings of top conferences and individual suggestions. Training compute is entered directly from publications where reported; where it is not, Epoch estimates it either by counting operations from the model architecture and training data — the preferred method when enough information exists — or from hardware details and usage. Confidence in the recorded compute, parameter and dataset-size values is labelled as a 90% confidence interval: "Confident" within a factor of 3, "Likely" within a factor of 10 and "Speculative" within a factor of 31. The dataset distinguishes notable models (state-of-the-art improvement on a recognized benchmark, over 1,000 citations, historical relevance, or significant use), frontier models (in the top 10 by training compute at release), and large-scale models (trained with over 10^23 FLOP, described by Epoch as a static threshold used in some AI regulatory frameworks). Epoch's documentation states that entries are added near-daily — newly released models and older models newly identified as notable — and that the downloadable CSV files are updated daily. The dataset page recorded an update of 10 July 2026 when fetched for this page.

Question 8

At what training compute does the EU AI Act presume systemic risk in a general-purpose AI model?

Accepted Answer

Under Article 51(2), a general-purpose AI model is presumed to have high impact capabilities "when the cumulative amount of computation used for its training measured in floating point operations is greater than 10^25" — the trigger for classification as a general-purpose AI model with systemic risk. Article 51(1) sets two classification routes: the model has high impact capabilities evaluated on the basis of appropriate technical tools and methodologies, including indicators and benchmarks (point (a)), or the Commission decides, ex officio or following a qualified alert from the scientific panel, that it has equivalent capabilities or impact having regard to the Annex XIII criteria (point (b)). Article 51(3) empowers the Commission to amend the thresholds by delegated act in light of developments such as algorithmic improvements or increased hardware efficiency. Article 52 sets the procedure: the provider must notify the Commission without delay and in any event within two weeks after the Article 51(1), point (a) condition is met or it becomes known that it will be met (52(1)); the provider may present substantiated arguments that the model nonetheless does not present systemic risks (52(2)), which the Commission shall reject where it finds them not sufficiently substantiated (52(3)); the Commission may also designate a model ex officio (52(4)); providers may request reassessment at the earliest six months after the designation decision (52(5)); and the Commission publishes and keeps up to date a list of general-purpose AI models with systemic risk (52(6)). Chapter V has applied since 2 August 2025 under Article 113, third paragraph, point (b), a date left unchanged by Regulation (EU) 2026/1744; the full timeline appears at the end of this page.

Question 9

What does the NIST AI Risk Management Framework's MEASURE function cover during development?

Accepted Answer

The MEASURE function employs quantitative, qualitative or mixed-method tools, techniques and methodologies to analyze, assess, benchmark and monitor AI risk and related impacts; the framework states that AI systems should be tested before their deployment and regularly while in operation. Section 5.3 of NIST AI 100-1 places MEASURE between the framework's other functions: it uses knowledge relevant to AI risks identified in MAP and informs MANAGE. The framework describes measurement processes that include rigorous software testing and performance assessment with associated measures of uncertainty, comparisons to performance benchmarks, and formalized reporting and documentation of results, and states that processes for independent review can improve the effectiveness of testing and can mitigate internal biases and potential conflicts of interest. Its stated outcome is that objective, repeatable or scalable test, evaluation, verification and validation (TEVV) processes — including metrics, methods and methodologies — are in place, followed and documented. Four categories organize the function: MEASURE 1, appropriate methods and metrics are identified and applied; MEASURE 2, AI systems are evaluated for trustworthy characteristics, with subcategories that include documentation of test sets, metrics and tools, demonstrated validity and reliability, safety, security and resilience, transparency and accountability, and explanation and validation of the model; MEASURE 3, mechanisms for tracking identified AI risks over time are in place; MEASURE 4, feedback about efficacy of measurement is gathered and assessed. The framework is a voluntary publication of the U.S. National Institute of Standards and Technology.

Question 10

Which life-cycle processes does ISO/IEC 5338 define for developing an AI system?

Accepted Answer

ISO/IEC 5338:2023 sets out the processes and supporting concepts through which the life cycle of an AI system built on machine learning or heuristics is described, building on the generic life-cycle standards ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 12207 with AI-specific processes from ISO/IEC 22989 and ISO/IEC 23053. Clause 5 sets out key concepts, including AI system concepts, the AI system life cycle model and process concepts. Clause 6 defines the life-cycle processes in four groups: agreement processes (6.1), organizational project-enabling processes (6.2), technical management processes (6.3) and technical processes (6.4) — the last group containing the architecture definition, design definition, implementation, verification and validation work of this stage. The introduction illustrates why generic software processes required extension: an AI-specific life-cycle characteristic arises where a system employs machine learning and it becomes necessary to retrain its model on new training data that better reflects current production data. The document records that its processes serve to define, control, manage, execute and improve the AI system across its life-cycle stages, and that they can be applied within an organization or a project when developing or acquiring AI systems; where an element of an AI system is traditional software or a traditional system, the ISO/IEC/IEEE 12207 and 15288 processes can implement that element. An informative annex records observations based on the use cases in ISO/IEC TR 24030, and the document states that it provides further detail on the AI system life-cycle processes discussed in ISO/IEC 42001. Paraphrased from the ISO text as previewed on the ISO Online Browsing Platform.

Question 11

What record of the training run must providers keep?

Accepted Answer

For high-risk AI systems, Annex IV point 2 requires the technical documentation to describe the development process, including under point 2(c) the system architecture and "the computational resources used to develop, train, test and validate the AI system". For general-purpose AI models, Article 53(1)(a) requires technical documentation containing at minimum the Annex XI information. Annex IV point 2(a) covers the methods and steps performed for development, including recourse to pre-trained systems or tools provided by third parties and how they were used, integrated or modified. Point 2(b) covers design specifications: the general logic of the system and its algorithms, the key design choices with rationale and assumptions, what the system is designed to optimise for, the relevance of the different parameters, and decisions on trade-offs made to satisfy Chapter III, Section 2. For general-purpose AI models, Annex XI Section 1 requires, among other elements: the architecture and number of parameters (point 1(d)); the design specifications of the model and training process, including training methodologies and techniques and key design choices (point 2(b)); "the computational resources used to train the model (e.g. number of floating point operations)" and training time (point 2(d)); and known or estimated energy consumption (point 2(e)), which may be based on computational resources where unknown. Models with systemic risk add Annex XI Section 2: evaluation strategies and results, adversarial-testing measures (such as red teaming) and model adaptations, and a description of the system architecture. Under Article 53(1)(a), the model documentation is drawn up and kept up to date for the purpose of providing it, upon request, to the AI Office and the national competent authorities.

Application date (Art. 113, as amended)	Provisions applying
2 February 2025	Chapters I and II — general provisions and prohibited AI practices (Art. 113, point (a)); the prohibitions inserted by Regulation (EU) 2026/1744 at Art. 5(1), points (ba) and (bb), and Art. 5(1a) and (1b) apply from 2 December 2026
2 August 2025	Chapter V (general-purpose AI models, including Arts. 51–53 and Annex XI documentation), Chapter III Section 4, Chapter VII, Chapter XII and Art. 78, with the exception of Art. 101 (Art. 113, point (b))
2 August 2026	General application, including Chapter III Section 5 (Arts. 40–49: harmonised standards, conformity assessment, certificates and registration), Art. 6(5), Art. 50 (transparency) and Chapter IX (post-market monitoring, information sharing and market surveillance)
2 December 2027 and 2 August 2028	Chapter III Sections 1, 2 and 3 (Arts. 6–27, except Art. 6(5)) — high-risk classification, the requirements for high-risk AI systems including Art. 15 and the Annex IV technical documentation, and the obligations of providers and deployers: from 2 December 2027 where a system is high-risk under Art. 6(2) and Annex III, and from 2 August 2028 where it is high-risk under Art. 6(1) and Annex I (Art. 113, points (c) and (d), as amended)

Explore 1BusinessWorld

Welcome to 1BusinessWorld

Model Design, Architecture & Training