Re: UPDATED, for immediate action! [was] Draft EU Commission guidelines on the classification of high-risk AI system

*Dear Paola, Lars, Wolfgang, Milton, and all,*

Thank you all for the thoughtful discussion. I found the different
perspectives highly complementary, particularly as the conversation has
evolved from interpreting the EU AI Act towards considering how these ideas
can be implemented in practice.

I found Wolfgang's proposal for a deployment declaration particularly
valuable. Capturing deployment-specific context provides an important
foundation for accountability, governance and transparency. Likewise,
Milton's proposal to develop a proof of concept for an ocean digital twin
is especially interesting, as real-world implementations often expose
interoperability and deployment challenges that are difficult to identify
through legislative analysis alone.

Reading the discussion, one question stood out to me. Beyond *what*
information should be recorded (classification, deployment context,
evidentiary records and authorisation state), there is also a broader
interoperability question:

*How do independent parties reliably discover, exchange and verify that
information?*

To me, it is useful to distinguish four related but independent concerns:

   - *Governance* – what information should exist and under what legal
   framework.
   - *Representation* – how that information is expressed in a
   machine-readable form.
   - *Discovery* – how another party knows where to find it.
   - *Verification* – how claims can be attributed and trusted.

Keeping these layers separate allows governance requirements to evolve
independently of any particular technical implementation while still
enabling interoperable solutions.

I also believe there is an operational aspect worth considering. We are
already seeing the emergence of multiple protocols and interaction models
for AI systems, each addressing different aspects of the ecosystem. It
seems likely that these will continue to coexist rather than converge into
a single approach.

For website owners, software providers and public-sector deployments,
implementing and maintaining multiple protocol-specific interfaces could
become increasingly complex and costly over time. This reinforces the value
of common capability descriptions, discoverable metadata and
implementation-independent abstractions that can be mapped onto different
interaction protocols as the ecosystem evolves, rather than requiring every
publisher to independently support every protocol.

Similarly, today many AI systems obtain contextual information by rendering
and analysing entire web pages, executing JavaScript and inferring
capabilities from user interfaces. While this remains an important
compatibility layer for today's web, it is computationally expensive and
may not represent a scalable long-term architecture as autonomous agents
become more common. Where structured deployment and capability information
is available, it should ideally be discoverable directly rather than
inferred indirectly. Besides improving interoperability, this also has the
potential to reduce unnecessary computation, bandwidth and energy
consumption.

I also think the distinction between *provider-declared properties*,
*deployment-specific
context*, and *runtime authorisation state* is an important one. These
concepts are closely related, but they represent different layers of the
system and should remain independently attributable and verifiable.

Whether future interoperability is achieved through well-known URIs, link
relations, signed metadata, or another discovery mechanism is, in my view,
secondary. The more important objective is ensuring that independently
developed systems can reliably discover, interpret and verify deployment
context without coupling governance guidance to a specific technical
approach.

For transparency, I have been exploring similar questions from an
implementation perspective through work on the open AI2Web interoperability
specification. My intention here is not to advocate a particular approach,
but to contribute implementation experience and to better understand the
architectural principles that could support interoperable and verifiable
deployment metadata across the ecosystem.

I look forward to seeing how this discussion develops and to learning from
the proof-of-concept work and other implementation experiences shared
within the group.

Best regards,

*Roland Farkas*
*Editor, AI2Web Specification*

On Sun, 26 Jul 2026 at 16:42, Milton Ponson <rwiciamsd@gmail.com> wrote:

> Dear all,
>
> I have read the submitted document on behalf of the AIKR CG with input
> from the AI Agent Protocol and reference to the A2WF CG.
>
> I also checked for the complete list of all relevant documents of the EU
> AI Act pertaining to its phased introduction and roll-out.
> https://share.google/aimode/oHyXdvECN20Fw1mZb
>
> As stated in earlier posts I am particularly interested in the development
> of digital twins for terrestrial and marine (coastal and ocean)
> (very)(large) ecosystems that can include one or more of the three
> components of sustainable development,  i.e. economic development, social
> development or ecological management.
>
> The EU has developed the BioDT, DestinE and EDITO (ocean digital twin)
> frameworks.
> Of these the EDITO is relevant for projects that we are developing in
> collaboration with the UNEP Caribbean Environmental Programme (CEP-UNEP),
> Grid Arendal Blue Carbon Program, the UNESCO Man and Biosphere Programme,
> which recently designated the Dutch Caribbean island of Aruba as the second
> full territory Biosphere Reserve on earth.
> Because Aruba is one of the 13 Overseas Countries and Territories of the
> European Union we will be using the EU AI Act and other relevant documents
> to guide the entire process of designing an ocean digital twin for Small
> Island Developing States (SIDS),  and use the Caribbean and South Pacific
> as geographical frameworks of reference.
>
> I have dealt with complex legislation at the UN level for climate, ocean
> and marine biodiversity, and also waste management and pollution issues,
> but the EU AI Act is the single most complex legislation I have encountered
> so far.
> Because I now must combine both multiple legal UN frameworks (treaties)
> and the EU AI Act to design the ocean digital twin for SIDS I must create a
> strategy,  complete with planning, deliverables ( both UN treaty and EU AI
> Act defined and mandatory) for the creation of proof of concept and pilot
> project phases.
>
> For the preparatory,  preliminary processes I am considering doing this in
> a manner that allows StratML application.
>
> But I am also open to suggestions for frameworks to assess which parts of
> the EU AI Act are applicable for the development of a digital twin for the
> ocean.
>
> The current use of technologies applied in ocean observation and
> monitoring covers a scope of artificial intelligence applications that
> exceeds the boundaries of what is framed in the EU AI Act.
>
> The creation of a proof of concept project and pilot project could provide
> valuable case study testing of the EU AI Act.
>
> I will soon be making more information available on the
> ecodigitaltwins.org website (under construction) on the setup.
>
> Again I am open to suggestions on how to proceed with the strategy,
> planning and automated processes for designing such a digital twin and als
> welcome the possibility of collaboration.
>
> Milton Ponson
> Rainbow Warriors Core Foundation
> CIAMSD Institute-ICT4D Program
> +2977459312
> PO Box 1154, Oranjestad
> Aruba, Dutch Caribbean
>
> On Sat, Jul 25, 2026, 04:49 Paola Di Maio <paoladimaio10@gmail.com> wrote:
>
>> Thank you everyone who contributed input to the consultation
>> It was submitted
>>
>> The actual consultation form on the EC consultation website did not
>> include the option to upload a PDF, rather requested
>> input in a structured questionnaire, I have however managed to insert a
>> link to the working draft note as a background reference which in turn
>> contains a link to this thread
>>
>>
>> https://docs.google.com/document/d/15cc-DtpWqCvGZUpvlaA-PklLIivR-RjnuwXvgqK08tE/edit?tab=t.0#heading=h.ky80zbid0xb6
>>
>> The note says it is work in progress/ the basis for ongoing discussions
>>
>> This consultation is important because in the whole landscape mapping,
>> 'high risk AI' is something to be aware of,
>> and by making explicit concepts and terminologies in use, we can keep
>> track of the evolution of knowledge in this domain
>>
>> I ll be glad if CGs touched by this topic would contribute to elaborate a
>> standard vocabulary that can facilitate knowledge
>> exchange and reuse, because the topic is likely to grow in importance and
>> impact on the industry as a whole
>>
>> Please continue to consider crystallizing a vocabulary and concept map
>> for this domain, at a minimum to support
>> understanding and eventually, when we coalesce, to be ready to put
>> forward  a vocabulary for standardization.
>>
>> Wishing  everyone an ongoing restful summer
>>
>> PDM
>>
>>
>> On Tue, Jul 21, 2026 at 5:31 PM Lars Kersten Kroehl <lars@moltrust.ch>
>> wrote:
>>
>>> Greetings AI KR CG Participants,
>>>
>>> I build DID/VC verification infrastructure for autonomous agents,
>>> including a deployed layer that anchors per-action verdicts against a
>>> committed mandate. I comment here because Section 2 touches a problem I run
>>> in production: the relationship between an evidentiary record and the
>>> authorization it is supposed to attest.
>>>
>>> == On §2.2 and §2.3: the record and the delegation should anchor at the
>>> same point ==
>>>
>>> Sections 2.2 (evidentiary record) and 2.3 (speaks-for authority) address
>>> two halves of one question, and the draft does not yet connect them.
>>>
>>> A content-addressed record of a commitment and decision establishes that
>>> an action occurred and by which identity. It does not, on its own,
>>> establish that the delegation authorizing that action held at the moment
>>> the action was taken. For a static system this gap is invisible. For an
>>> agentic system whose authorization can be narrowed, delegated onward, or
>>> revoked between classification and action, it is the substance of the
>>> question 2.3 raises: after a fork, identifying which instance acted is not
>>> the same as establishing that the acting instance was authorized at that
>>> time.
>>>
>>> The practical consequence for record-keeping guidance: an evidentiary
>>> record satisfying Article 12 should commit the identity, the decision, and
>>> the authorization state in force at the moment of the action. Without the
>>> last, a fork preserves the classification but not the binding that made the
>>> action accountable. Whether this belongs in the guidelines or in the
>>> referenced technical work (W3C AI Agent Protocol CG) is a scoping question
>>> for the group.
>>>
>>> Whether this bears on the Article 25(1) provider-obligation transfer —
>>> where a fork or substantial modification may move provider status to
>>> another party — is a legal question outside our competence.
>>>
>>> Best,
>>> Lars
>>>
>>>
>>>
>>>
>>>
>>>
>>> Am 21.07.2026 um 16:07 schrieb Paola Di Maio <paola.dimaio@gmail.com>:
>>>
>>> Greetings AI KR CG Participants
>>>
>>>
>>>
>
>
>
>