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

Dear Paola, dear all,

Thank you, Paola, for the excellent distillation, and thank you, Isaac, for
introducing the concept of derived, relational classification. I'd like to
contribute what I believe is the missing counterpart to Sections 2.1–2.3,
based on practical implementation experience.

Over the past months, the W3C A2WF Community Group (a2wf.org) has been
working on exactly this challenge: a machine-readable deployment
declaration (siteai.json at a well-known URI) that allows websites and
service operators to publish information about their AI usage, permissions,
governance, human oversight and transparency measures. We also developed an
EU Governance Starter Profile aligned with AI Act Articles 6, 13, 14, 26
and 50, together with relevant GDPR provisions.

One thing became very clear during implementation, and it closely matches
Isaac's observations:

   1. *Classification is inherently relational.* The same embedded chatbot
   may be low risk on a restaurant website but potentially high risk when
   deployed in a medical triage setting. Agent-bound attributes alone cannot
   capture this difference; the deployment context also needs to be available.
   2. *Discovery is the real challenge.* Our validator and EU readiness
   checker only work because there is a predictable place where deployment
   information can be found using a well-known URI with a legacy fallback.
   Without a common discovery mechanism, the goal of transporting and
   verifying information between independent parties becomes very difficult to
   achieve.
   3. *The provider/deployer boundary causes the greatest uncertainty.* The
   most common question we receive is: *"We are embedding a third-party AI
   widget. Who is actually responsible for the classification?"* I believe
   the draft guidelines would benefit greatly from including practical
   examples addressing this distinction.

Based on these experiences, I would like to suggest the following text for
possible inclusion after Section 2.3. I intentionally wrote it in
technology-neutral language so that the submission does not endorse any
particular implementation or format, including our own. Please feel free to
shorten it or integrate the ideas wherever they fit best.
2.4 Deployment-side context declaration and discovery (draft)

Where classification depends on intended purpose and operational context,
system-bound classification attributes should be complemented by a means of
discovering how the system or component is actually deployed. The
Guidelines should recognise machine-readable deployment context
declarations as a voluntary interoperability mechanism, particularly for
embedded third-party components such as chatbots, recommenders, triage
tools, and decision-support services.

Such a declaration could identify the declaring entity and its role, the
relevant system or component, its actual deployment purpose and
capabilities, applicable human oversight and transparency arrangements, and
the contextual assumptions used in a classification analysis. It should be
attributable, versioned, and linked to supporting evidence where
appropriate. Public discovery does not necessarily imply public access to
all supporting material; layered access may be necessary to protect
personal data, security-sensitive information, and trade secrets.

A deployment context declaration would not itself determine whether a
system is high risk. It would not replace provider assessments,
documentation, registration, conformity assessment, or any other
obligations under the AI Act. In particular, assessments performed by
providers under Articles 6(3) and 6(4) should remain clearly distinct from
contextual information supplied by deployers. Any such mechanism should
remain technology-neutral and non-exclusive and should not pre-empt future
Commission guidance, harmonised standards, common specifications or
sector-specific requirements. Well-known URIs, link relations, signed
metadata or comparable discovery mechanisms could all support
interoperability without endorsing a specific technical format. The
objective is discoverable and verifiable context rather than self-certified
compliance.
Proposed glossary addition (3.5)

*Deployment context declaration* – A machine-readable, attributable and
versioned statement made available by a deploying party or system operator
describing the operational context in which an AI system or component is
used, including its actual purpose, deployed capabilities, relevant human
oversight and transparency arrangements, and contextual assumptions
relevant to risk classification. It supports discovery and evidence
exchange but does not itself determine legal status or replace
documentation, registration, conformity assessment or other obligations
under the AI Act.

If it would be helpful for the submission's evidence base, A2WF is MIT
licensed and already includes a working validator, a generator wizard and
an EU governance readiness checker. We would be happy to serve as a
practical example demonstrating that deployment context declarations are
already technically feasible today, while making it clear that A2WF is an
experimental community specification rather than a normative proposal. For
transparency, I am one of the editors of that specification.

Looking beyond this consultation, I also see an interesting opportunity for
collaboration between AI KR's knowledge representation work, the AI Agent
Protocol Community Group's agent-bound attributes, and A2WF's
deployment-side declarations. Together, these three layers could provide a
much more complete and verifiable governance model for agentic AI. I'd be
happy to explore this further after the consultation deadline.

Finally, may I request edit access so that I can insert the proposed
Section 2.4 as tracked changes before noon tomorrow? I am equally happy to
be acknowledged or to remain anonymous.

Best regards,

*Wolfgang Wimmer*
Editor, A2WF Specification

On Tue, Jul 21, 2026 at 8:01 PM Paola Di Maio <paoladimaio10@gmail.com>
wrote:

>
> Lars and everyone, thanks
> I have updated the note as follows as per the discussion
>
> https://docs.google.com/document/d/1xbnOx7d8I4aUTLczbdkiL9Ttafl6iDbm3h6RsYWktLw/edit?usp=sharing
> Please send additional suggested edits and comments before 23 July-
>
>
> *Changelog — Consultation submission revisions*
>
> *Section affected:* 2.3 only — "Open question for the guidelines:
> classification persistence across lifecycle events." All other sections
> unchanged.
>
> *Change 1 — New paragraph added* (connecting 2.2 and 2.3):
> Added a paragraph arguing that an evidentiary record establishing *who
> acted* is not the same as establishing that the *authorization* for that
> action still held at the time it was taken. Recommends that an Article 12
> record commit identity, decision, *and*
> authorization-state-at-time-of-action, not just the first two. Flags two
> open scoping questions: (a) whether this level of detail belongs in the
> Commission's guidelines or in referenced technical-standards work, and (b)
> whether it bears on the Article 25(1) provider-obligation transfer —
> explicitly left unanswered as outside the group's competence. Sourced to a
> mailing-list thread (linked, no name attached).
>
> *Change 2 — Test-bed citations rewritten:*
> The two supporting-project references were reframed from reading as one
> combined grounding into two clearly separate, early-stage, unreviewed items:
>
>    - Added repo-age context for the lifecycle write-up (created April
>    2026, small star count).
>    - Clarified the second project is a different, single-author work (not
>    connected to the first repo), noted it's a Zenodo self-publication, not
>    peer-reviewed, and flagged that its "verification" claim was added weeks
>    after the original publication and hasn't been independently checked by
>    anyone, including the group.
>
> *Change 3 — Closing line added:*
> A sentence clarifying both projects are offered only as illustrative test
> beds, and that the section's conceptual argument doesn't depend on either
> project's claims holding up.
>
>
> 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
>>
>>
>>