Highlights

From the 68th General Assembly

As a rule, MPAI holds a General Assembly (GA) every four weeks. It does so because its rigorous standard development process requires that approval of documents be made by a GA where all Principal Members are assembled. Of course, the technical work is made by Development Committees where all members can participate and contribute to the development of documents and standards.

The last GA (MPAI-68) has achieved several important results. The first was the final approval of two draft standards that were published for Community Comments – AI for Health (MPAI-AIH) and Neural Network Watermarking – Technologies (NNW-TEC). The second was the decision to submit NNW-TEC and MPAI-AIH to IEEE for adoption without modification as P3315 and P3316, respectively. The third is the approval of a working draft of Process Instance Trust Framework (MPAI-PTF) of which more is said in the body of this newsletter, and of AI Passport, a new project of which more will be said in a future newsletter.

Tracking a neural network

1          Introduction

During the last decade, Neural Networks have been deployed in an increasing variety of domains, and the production of Neural Networks became costly, in terms of both resources (GPUs, CPUs, memory) and time. Moreover, users of Neural Network based services expect to receive neural network (NN)-based services with certified quality.

NN Traceability offers solutions to satisfy this need, ensuring that a deployed Neural Network is traceable and untampered with.

Inherited from the multimedia realm, watermarking regroups a family of methodological and application tools allowing the imperceptible and persistent insertion of some metadata (payload) into an original NN model. Subsequently, detecting/decoding this metadata from the model itself or from any of its inferences provides the means to trace the source and to verify its authenticity.

An additional traceability technology is fingerprinting that relates to a family of methodological and application tools allowing the extraction of some salient information from the original NN model (a fingerprint) and the subsequent identification of that model based on the extracted information.

Therefore, MPAI has found the application area called “Neural Network Watermarking” to be relevant for MPAI standardization as there is a need for both Neural Network Traceability technologies and for assessing the performances of such technologies, as illustrated in Figure 1.

Figure 1: NNW-NNT TEC overview

2          MPAI available standards

In response to these needs, MPAI established the Neural Network Watermarking Development Committee (NNW-DC) in 2022. The DC developed a series of incremental and complementary standards (Technical Specifications), as illustrated in Figure 2:

  • Technical Specifications – Neural Network Traceability (NNW-NNT) V1.0 issued in November 2024 that specifies methods to evaluate aspects of Active (Watermarking) and Passive (Fingerprinting) Neural Network Traceability Methods. This standard extends Technical Specification – Neural Network Watermarking (MPAI-NNW) V1, issued in January 2023, with Passive Techniques. Specifically, NNW-NNT addresses, for both Active and Passive techniques:
    • The ability of a Neural Network Traceability Detector/Decoder to detect/decode/match Traceability Data when the traced Neural Network has been modified,
    • The computational cost of injecting, extracting, detecting, decoding, or matching Traceability Data,
    • Specifically for active tracing methods, the impact of inserted Traceability Data on the performance of a neural network and on its inference.
  • Technical Specification: Neural Network Watermarking (MPAI-NNW) – Technologies (NNW-TEC) V1.0, issued in May 2026. This newest standard goes further in answering industrial needs by providing normative tools that:
    • Characterizes Neural Network Traceability technologies and their usage, so that appropriate Actors can:
      • verify that the data provided by an Actor and transported to another Actor is not compromised, i.e. if modified, the modifications allow data to be used for the intended scope.
      • identify the Actors providing and receiving the data.
    • Uses the MPAI NNW-NNT Technical Specification to evaluate the properties of Neural Network Traceability technologies that comply with the general procedure specified by NNW-NNT and are applicable to specific classes of Neural Networks and are used in specific application domains.

NNW-TEC Technical Specification Versions are snapshots capturing the evolution of the general procedure and of the performance of implementations, and the current version evaluates 3 Traceability Technologies.

Figure 2: NNW-DC results: three MPAI Technical specifications, among which two are also promoted as IEEE standards

 

Sample results from NNW-TEC are presented in Table 1 and Table 2 for 3 traceability technologies: No-Constraint Traceability (NCT), Regularization-Term Watermarking (RTW), and Trigger-Based Watermarking (TBW).

Table 1 provides samples of Imperceptibility results, with α (the epoch of insertion of the mark for NCT), N (the number of marked parameters for NCT), λ (hyperparameter of RTW), and ρ (hyperparameter of TBW). Table 2 provides the results for Computational Cost.

 

Table 1 Samples of Imperceptibility results.

Method Model Parameter Relative variation of the classification error
NCT VGG16 N=64, α=0 0
N=16144, α=90 1
ResNet8 N=64, α=0 0
N=16144, α=90 192
RTW VGG16 λ= 0.01 2
ResNet8 λ= 0.01 5
TBW VGG16 Rho = 10 7
ResNet8 Rho = 10 7

 

Table 2 Samples of Computational Cost results.

Method Average number of batch iterations to insert the mark Increased batch iteration time (%)
NCT 0 0
RTW 500 16.64
TBW 504 62.69

 

3          MPAI NNT-TEC Actors

Under the scope of NNT-TEC, six types of Actors are identified as playing a traceability-related role in the use cases.

  • Architects: design the architecture of the model
  • Trainers: train the models for a purpose
  • Trackers: provide tracking technologies
  • Distributors: distribute trained models with tracking technology
  • Generic users: any users intended by the Distributors
  • Attackers: any users, be they intended or not by the Distributor, that apply a modification to the Neural Networks subjected to Traceability Technologies.

4          MPAI NNT Service and application scenarios

MPAI NNT is relevant for services and applications benefitting from one or several conventional NN tasks such as:

  1. Video/image/audio/speech/text classification
  2. Video/image/audio/speech/text segmentation
  3. Video/image/audio/speech/text generation
  4. Video/image/audio/speech decoding

Figures 3, 4 and 5 present three types of services and applications aggregating these four listed conventional NN tasks.

The first example (Traceable newsletter service – Figure 3) covers the case where an end-user (acting as a Generic user) subscribes to a newsletter that is produced by a Generative AI service (acting as a Distributor), according to the end-user profile. In such a use case, a malicious user (acting as Attacker) might try to tamper with the production of the personalized content or modify it during its transmission.

Figure 3: NNT-TEC use-case example: AI-generated newsletter example

 

The second example (Autonomous vehicle services – Figure 4) deals with the traceability and authenticity of the multimodal content that is exchanged in various ways: (1) the car A (acting as an Generic user) sends to a server (acting as an Distributor) acquired signals for data-processing, (2) An embedded AI transmits instructions such as braking, turning, or accelerating to the car (acting as an Generic user), (3) Another vehicle, vehicle B, in the environment transmits environmental information to vehicle A. Various types of malicious attacks with critical consequences can be envisaged, like AI interception and corruption (e.g. malicious data sent to vehicle A to alter its learning) or data corruption in their transmission from and/or to the autonomous vehicle (data loss or modification).

Figure 4: NNT-TEC use-case example: Autonomous vehicle services

 

The third example (AI generated or processed information services – Figure 5) shows how NNT-TEC can be beneficial when genuine images are modified by a deepfake process. A user capturing a video sequence by a connected camera would like to appear as an archetypal secret agent (say, James Bond) by interacting with a generative AI service accessible in the network. This module synthesizes novel audiovisual content, which is then rendered on a display for the user to enjoy. Such services are not immune from security threats: the attacker can intercept the encoded stream prior to its arrival at the trusted AI server and process it through a malicious edge-deployed generative AI, or it can affect the trusted generative AI service (e.g. by employing an adversarial training technique).

Figure 5: NNT-TEC use-case example: AI generated or processed information services

Communication between processing entities

MPAI has made the identification of processing elements and their coordinated communication the foundational elements of its standards. One of the first MPAI standards was AI Framework (MPAI-AIF) specifying an environment enabling initialisation, dynamic configuration, and control of AI applications called AI Modules (AIM). These may have a hierarchical structure with “higher-level” AIMs including combinations of “lower-level” AIMs. Two-thirds of the MPAI standards published so far are based on the AI Framework. The MPAI Metaverse Model – Technologies (MMM-TEC) standard is not based on the AI Framework but introduces the notion of Processes communicating with other Processes to do things that they are not able to do by themselves or have no rights to do.

MPAI-AIF mandates that the environment in which data is passed between AIMs be “Zero-Trust”, but the Basic Profile of MPAI-AIF is silent on how such as a state can be reached. More recently, the Secure Profile was introduced, but it requires that if the AIM executed in the AIF is a Composite AIM, its component AIMs cannot access the Security API.

Version 3.0 of MPAI-AIF being developed introduces a few elements that enable richer and more secure AIM-to-AIM and Process-to-Process communication.

It first defines an AIM Instance as a specific implementation of an AIM used in an AIW and a Process Instance (PI) as either an AIM Instance or a Process. PIs need to communicate but how can PIA trust PIB? AIF V3.0 assumes that both PIA (Requesting Process Action) and PIB (Responder) have established trust with a Trust Anchor, as depicted in Figure 1. The Trust Anchor (TA) need not be monolithic, for instance PIA may be trusted by TAA and PIB by TAB, but the trusted relationship between TAA and TAB is a given.

Figure 6 – Process Instance Trust Frame

 

MPAI is developing a Protocol that establishes how TAA and TAB can establish Trust through the phases of Identity Verification, Credential Verification, Evidence Verification, Policy Evaluation, and Decision Logic.

Once trust is established, PIA and PIB can start communication. AIF V3.0 is using Data Exchange Metadata as a container for the following entities concerning the Data Instance transferred by PIA

to PIB: the legal, security, and authorised states and the confidence in the data accuracy.

The Security state consists of a set of metadata and cryptographic parameters that ensure the identity, secure transmission, integrity, encryption, and timestamps of Data exchanged between AIMs and AIWs. It relies on a Security Technology Taxonomy that the Security data type can reference. The Authorised state of data is communicated by the list of Process Instances that may process the data in conjunction with other listed data.

The Legal state of data depends on the state of the Process Instance that produced the data. MPAI has defined two data types: Machine Learning (ML) Model Object and ML Manifest. ML Model Object is a composition of ML Model Data resulting from the application to a Process Instance of training data and ML Model Qualifier specifying the meaning (format) of the data. ML Model Qualifier is an entry in the Data Types, Formats, and Attributes (MPAI-TFA) standard. This includes a natural-language description of the function performed by the ML Model Data, the ID of the Training Dataset used to train the ML Model, and the input and output data types

The types of AIMs and data are rigorously defined and uniquely identified in the MPAI Ecosystem. AIMs can be differently implemented as some of them have fewer functionalities. Different types of the same AIMs are differentiated by Profiles, and MPAI has developed a method to signal the Profile of an AIM.

Meetings in the May-June 2026 cycle

 

Group name 18-22 May 25-29 May 01-05 June 08-12 June Time (UTC)
AI Framework 18 25 1 8 15
AI-based End-to-End Video Coding 27 14
AI-Enhanced Video Coding 3 13
Artificial Intelligence for Health 21 1 8  14
Communication 21 4 13
Compression & Underst. of Industrial Data 1 8:30
19 8  9
Connected Autonomous Vehicle 28 4    11 14
Context-based Audio enhancement 19 26 2 9 16
Industry and Standards 22 5 16
MPAI Metaverse Model 21 28 4 11 15
Multimodal Conversation 19 26 2 9 14
Neural Network Watermarking 19 26 2 9 15
Portable Avatar Format 22 29 5 12 8
XR Venues 19 26 2 9 17
General Assembly (MPAI-69) 10 15