Highlights

 

Online presentation of “AI Passport” Call for Technologies

MPAI is continuing its launch of new standard projects with AI Technologies, a dataset describing the properties of an AI System for use by humans and machines alike. Online presentation events are scheduled for 10 September 2026. Register here for the 08:00 UTC and here for the 15:00 UTC presentation

 

The Call for Technologies: AI Passport (MPAI-AIP) V1.0

1.Background and Purpose

MPAI is developing a new standard called AI Passport (MPAI-AIP), aimed at creating a structured dataset that conveys standardised, machine-readable information about any AI system. The goal is to give both humans and other AI systems a reliable, unambiguous way to learn about an AI’s characteristics – its capabilities, origin, certifications, performance metrics, and measurable ethical properties – before deciding whether and how to interact with it.

The initiative is motivated by a recognised gap in the current regulatory and standardisation landscape. While frameworks such as the EU AI Act and ISO/IEC 4200x AI Governance are establishing legal and procedural obligations around AI, they do not specify practical, interoperable formats for adequately expressing the necessary information. The AI Passport is intended to fill that gap by providing a concrete, technically specified data format that regulators, developers, and users can all rely on.

2. Problem and Use Cases

MPAI is issuing an “AI Passport” Call for Technologies. The document identifies two broad interaction scenarios that the AI Passport must support.

Human-to-AI interaction covers situations where a person needs to evaluate an AI system before using it. This includes searching for an AI with specific capabilities, verifying that an AI meets legal or ethical requirements in a given jurisdiction, understanding the ground model and training data it was built on, knowing its input/output data types and protocols, and checking application-specific and general KPIs. It also covers commercial and regulatory contexts: companies drafting AI-related contracts want an authoritative technical reference, and regulatory bodies want a standard way to express and compare AI system information.

Machine-to-AI interaction covers situations where another AI or automated system needs to evaluate an AI before engaging with it. This includes searching a marketplace or repository for an AI with specific characteristics, and direct AI-to-AI decisions about whether to interoperate based on the other system’s published parameters, protocols, and compliance status.

3. Functional Requirements: The AI Passport Data Model

The AI Passport is defined as a structured dataset with the following principal fields:

Identity and provenance. Each AI Passport has a unique ID issued either by an authorised Agency or by the developers acting as their own agency. A separate AI System ID uniquely identifies the AI model itself. A Fingerprint – a hash function with bit-sensitivity and anti-collision properties – binds the Passport to a specific trained model instance; if the model changes, the hash changes.

Function. A natural language description of what the AI is intended to do.

Interfaces. Specification of the AI’s input and output interfaces, including the protocols used for data exchange, expressed via standard taxonomies.

Data. The data types consumed and produced, described both semantically (syntax, semantics, referencing MPAI or other standard data type specifications) and in terms of governance (the legislation and regulations under which the data was produced and is processed).

Certification. References to the legal, regulatory, or standards frameworks under which the AI has been certified.

Origin. The ground model or pre-trained architecture used as the basis for training, identified via a standard model identification system including a parent-child ID relationship. Training data is described by name, version, and a reference such as a DOI, URL, or DAO (Decentralised Autonomous Organisation).

KPIs. Both general application-independent KPIs (e.g. precision, area under the curve) and application-specific KPIs, with guidelines for the latter to be developed.

Ethical evaluation. Structured assessments across three dimensions – accountability, environmental impact, and social/dual-use considerations – each referenced to a corresponding taxonomy.

Technology environment. Hardware architecture (vendor, hardware type) and run-time environment (developer, name, version, operating system), both expressed via taxonomies.

4. Binding the Passport to the AI System

The Call notes that a critical open problem is how to reliably associate an AI Passport with a specific AI model instance. Three candidate approaches are outlined: (1) creating a macro-object that wraps the AI and its Passport together; (2) watermarking the AI model with a payload containing the Passport ID; (3) using a DAO or blockchain-based system for distributed tamper-evident governance. Respondents are invited to propose solutions.

5. What the Call Requests

The Call seeks contributions in three areas. First, taxonomies for all the enumerated fields – agencies, legislation, regulations, standard bodies, data types, protocols, KPIs, ethical methods, hardware architectures, and run-time environments – including procedures for extending them over time. Second, a standard identification system for AI models. Third, formats for representing the AI Passport itself and methods for binding Passports to AI systems.

6. Process and Timeline

The Call was issued on 19 August 2026. Online presentation events are scheduled for 10 September 2026. Register here for the 08:00 UTC and here for the 15:00 UTC presentation. Respondents should notify their intention by 27 September 2026 and submit full responses by 27 October 2026 at 15:00 UTC. Responses are evaluated by a panel that includes MPAI members, responding non-members, and invited experts. Evaluation criteria are completeness, understandability, implementability, complexity, reliance on established technologies, and the state of the proposed technology with respect to encumbering intellectual property. Respondents whose submissions are accepted will be required to join MPAI and commit to licensing any essential patents under the Framework Licence terms.

7. Significance

MPAI-AIP addresses a genuine and growing need. As AI systems proliferate and regulation intensifies, the absence of a standard machine-readable identity and capability descriptor for AI is an increasingly serious gap. The AI Passport concept bridges the technical and governance worlds: it gives regulators a practical enforcement handle, gives developers a standard way to publish their AI’s properties, and gives users and automated systems the information they need to make informed decisions about AI adoption and interoperability. If successfully standardised, it could become for AI systems what data sheets are for electronic components.

 

An AI Tool project – The Answer to Multimodal Question App

1          MPAI and its ecosystem

MPAI’s mission is the development of standards promoting the efficient use of data especially through the use of Artificial Intelligence (AI). Founded in 2020, it has already produced some 20 standards. Most of them are based on a processing environment called AI Framework (AIF – an MPAI standard). An AIF is a zero-trust environment populated by interconnected AI Modules (AIM). MPAI specifies function and interfaces (data, protocols, etc,) of an AIM. An AIM that includes interconnected AIMs is called Composite.

Figure 1 – The AI Framework Reference Model

Standards define ecosystems and MPAI defines its ecosystem as the set of the following interacting actors:

  1. MPAI – issues standards.
  2. Implementers – implement instances of MPAI standards.
  3. MPAI Store – assigns identifiers to Implementers, tests conformance of submitted implementations, and posts tested implementations.
  4. Performance Assessors – assess how well an implementation performs its function.
  5. End users – download and use implementations and may report about their satisfaction.

How does an implementation enter the MPAI Ecosystem?

The implementer produces an instance of a JSON schema that normatively “describes” the implementation as an instance of an application specified by an MPAI standard. This contains:

  1. The AIM Identifier composed of the Implementer ID and the unique identifier of the implementation assigned to it by the implementer.
  2. The external ports of the AIM as identified by their local names and the data types flowing through those ports. The data type names and formats have been standardised by MPAI.
  3. The data types used inside the AIM, again identified by the names and formats standardised by MPAI.
  4. The Sub-AIMs used by the AIMs identified by the names, functions, and interfaces standardised by MPAI.
  5. The Topology expressed by the AIMs’ connections – identified by the data types flowing through them – with the other AIMs in the AIF.
  6. Features of the Implementation – from where it is accessible, with what name, processing architecture, OS, Version, etc.
  7. Resources required for execution – Memory, CPU Class, etc.

2          The AI Tools project

The 71st MPAI General Assembly has launched the AI Tools standard Project. The goal is to make available a large number of AIMs to the MPAI Community for experiments. AI Tool implementations are released as Open-Source Software (3-Clause BSD licence). To provide an environment that is as realistic as possible for simulations, the AI Tools project requires that implementations provide sufficient elements of the MPAI Ecosystem.

Let’s see the operation of the AI Tools using the Answer to Multimodal Question (MMC-AMQ) application as an example. Specified by the Multimodal Conversation (MPAI-MMC) standard, an MMC-AMQ implementations enables a user to ask a question about an image expressed as speech or text and obtain an answer in speech or text.

Figure 2 – Reference Model of the Answer to Multimodal Question

This implementation aims to demonstrate the claim of the AI Framework (MPAI-AIF) standard that an MPAI application can be assembled from independently specified and independently implemented AI Modules, executed by the AIF that trusts none of them.

Here is how AI Tools simulates the operation of the MPAI Ecosystem.

An implementer does the following

  1. Develops an AIM
  2. Writes the AIM Metadata exactly as the standard prescribes: AIM Identifier, Ports and the Data Types they carry, and – if it is a Composite AIM – its Sub-AIMs and their Topology.
  3. Autonomously selects an implementer ID and an implementation ID.
  4. Uploads the AIM Metadata file of their implementation.

 

The Store – a simulation of the MPAI Store:

  1. Reads the AIM Metadata
  2. Rejects the AIM Metadata if not conforming (missing Identifier, wrong AIM Name etc.).
  3. Otherwise, the Metadata is published, and the AIM appears in the Store’s list.

 

The MMC-AMQ App activated by a user unfolds as follows:

  1. User opens the AMQ application and chooses an image, which appears in the window.
  2. AMQ prompts user into asking a question.
  3. User asks a question about it – in text or speech.
  4. AMQ outputs the answer text if question was text otherwise synthetic speech.

 

Inside, the AMQ components do the following:

  1. The User Agent asks the AIF to start the AMQ AIM.
  2. The Controller asks the Store for that AIM by name, reads the published Metadata, and finds it is a Composite AIM declaring three Sub-AIMs: Automatic Speech Recognition (MMC-ASR), Text and Image Query (MMC-TIQ), and Text To Speech (MMC-TTS).
  3. The Controller instantiates each Sub-AIM and turns the declared Topology into an execution plan. Everything the execution plan contains was read from the published AIM Metadata.
  4. If the User asks the question as speech, the User Agent’s Speech Object Acquisition module acquires it.
  5. The User Agent writes the image and the question to the Controller and asks to execute the plan once.
  6. The executor module works through the plan. Each AIM is handed the values whose Data Type its Ports accept, and nothing else: MMC-ASR receives the acquired speech and returns text; MMC-TIQ receives that text – or the typed question – together with the image, and returns the answer as text; MMC-TTS receives the answer and returns speech. An AIM whose inputs never arrive is skipped.
  7. The answer leaves the AIM on its boundary Ports. The User Agent reads them, displays the text, and plays the speech to the User through its Speech Object Delivery module.

 

What is worth noticing about step 6. The route from question to answer is not written anywhere in the application: it is in the implementer’s AIM Metadata. An AIM is given what it needs and no more – it cannot see the Store, cannot see the other AIMs, and cannot ask the framework for anything it was not handed. That is what “an AI Framework that trusts none of them” means in practice.

3          What the AIM Metadata says about AMQ

The question may be spoken or typed. The input Speech and Input Text are both declared as aoptional so id the user makes their question in one and not the other proceeds rather than suspends: the AIM that has nothing to work on is passed over, and the run continues.

Routing is by data type, not by Port name. The Controller’s executor relies on a Port’s data type. The name of a Port is just a label for human readers. Where an AIM declares two Ports of the same Direction and data type, a Port Number distinguishes them.

Speech acquisition and delivery are not SubAIMs. A microphone and a loudspeaker interact with the user directly. The output is passed to the User Agent, from there to the Controller. This reads the AMQ AIM Metadata, builds a graph, instantiates each SubAIM, and executes the Topology delivering speech or text to the appropriate AIMs.

4          What AIF zero trust means in practice

Zero trust here is not a slogan; it is a set of things the code is prevented from doing.

  • An AIM cannot see the Metadata repository. An AIM receives the AIM Metadata from the Controller that receives it from the Store.
  • The User Agent cannot reach into a running AIM. Everything the application wants of an AIM must be requested via the Controller.
  • No AIM calls another AIM. One AIM receives the result on a Port, because the Topology says so. The dependency moves from inside an AIM to the application that assembles them, where it is visible.
  • Provenance is stamped, not supplied. Shared Storage records which AIM Instance wrote a value when. The caller supplies neither, which is what makes the record trustworthy.

5          The User Agent, and why it needs a workflow manager

The User Agent holds everything that touches the person: the image window, the image chooser, the microphone through Speech Object Acquisition (acquires speech from microphone/transport device) and the loudspeaker through Speech Object Delivery (sends to speaker or transport device).

The User Agent also holds the order of events. The AIF executes the AMQ AIM from source to sink; it does not know that an image must be shown before a question can be asked about it, that recording begins when a button is pressed and ends when it is released, or that the answer should be spoken only after it has been displayed. That sequence is the User Agent’s business, and it is why a User Agent is a sequence manager.

Concretely, one interaction is: show the image, wait, capture the question, start the appropriate AIMs, write the image and the question to their boundary Ports, run once, read the three outputs, display and speak.

6          The models

  • MMC-ASR – Whisper (ggml-small, 465 MB).
  • MMC-TIQ – BLIP for visual question answering: the image and the question in, a text answer out.
  • MMC-TTS – Piper, one ONNX voice per language, each about 60 MB. A language with no voice installed falls back to the default voice, which is just audible.

7          The networked version

The networked version of MMM-AMQ intends to simulate the operation of MPAI as a Service (MPAI-MAS), The reference figure shows:

  1. Remote Client, holding an API Client and the Client Application;
  2. MPAI as a Service, holding the Server API and a Controller;
  3. MPAI Store.

The Client speaks to the AIF Remote API; the Server speaks to the Controller of the AIF Basic API; and the AIF Enhanced API speaks to the Store; AIM Metadata reaches both from a Repository.

Figure 3 – Reference Architecture of “MPAI as a Service”

  • The Service hosts the Controller, loads the models, and exposes the AIF Remote API over HTTP.
  • The Remote Client is the same window as the standalone application, So the AIMs run on the server while the microphone, the loudspeaker and the screen stay with the person.
  • A program starts the server, waits for it to answer, starts the client, and then stops the server when the client closes.

The same window runs in standalone and networked modes; what differs is only where the AMQ AIM executes. Acquisition and delivery travel with the client.

Meetings in the August-September 2026 cycle.