Re: We should require AI disclosure
Guus der Kinderen <[email protected]> Wed, 8 Jul 2026 11:04:45 +0200
| Newsgroups | gmane.network.jabber.standards-jig |
|---|---|
| Message-ID | <CAMJaV9=ci3RYuJZWGBh0j0gVmMQCyh602tghFW1RKh8xvDV2ug@mail.gmail.com> |
--===============7053063961094549560==
Content-Type: multipart/alternative; boundary="0000000000003da96b065615cd27"
--0000000000003da96b065615cd27
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi all,
Some thoughts, having read the thread through again.
On disclosure: I understand the appeal. Mattj puts the strongest version of
the case: that we're currently in the dark about how these tools are being
used in our community. My hesitation is with making it a requirement. A
requirement will mostly be honoured by people who aren't producing the
submissions we broadly agree we want to stop, while the people producing
those are unlikely to honour it. Without assignable consequences it doesn't
bite, and my worry is that it mainly burdens contributors who are making
perfectly good use of these tools. Goffi points to llama.cpp and CPython. I
don't know enough about how those requirements work in practice to say
whether they transfer here. Both, I suppose, are handling code
contributions with automated test suites behind them, which is maybe a
rather different review problem to ours?
One thing I think we should do regardless: Ralph proposed a sentence for
XEP-0143, that authors must understand, verify, and take responsibility for
every contribution they submit. That seems worth having written down
whatever else we decide, so I've opened a PR for it:
https://github.com/xsf/xeps/pull/1552. It is deliberately not AI-specific,
and is not intended to settle anything else in this thread.
Which brings me to what I think is the actual problem. One of the XSF's
most valuable assets is the volunteering force that helps us achieve our
goals. We have not historically done a great job at preventing burnout
among those volunteers, and we need to do better. If we do start receiving
large volumes of AI-generated slop (and I don't think that has happened
yet, but we would be wise to prepare) it carries a significant risk of
adding to those burdens. Kev's point about the Editor role, and about the
effort asymmetry between generating and reviewing a submission, seems to me
the concrete harm we should be organising around. Not copyright, and not
disclosure for its own sake.
So rather than "disclose AI", I'd like us to think about what we actually
need in order to identify and handle low-quality submissions at volume,
whatever produced them, AI or humans. Two things I think we need in order
to have that conversation properly:
First, prior art. Goffi, you're the one with the most energy on this and
you're seeing it from the Council side. Would you be willing to take this
on? Kev hinted at the GSoC mentor discussions this year, and the IETF has
apparently seen entire suites of AI-generated Internet Drafts. Other
organisations are dealing with this right now, and I'd like to know what
they've tried and how it worked out before we invent our own approach. It's
well-bounded work, and if it comes back showing that disclosure
requirements are doing real work elsewhere, that's an argument I'd want to
hear and one that would carry weight with Board.
Second, procedure. If we identify a submission as slop, what happens? I
think we need to guard in two directions at once: against volunteers having
to process slop, and against submitters being rejected bluntly ("computer
says no").
MSavoritias made a point earlier: consensus is unlikely to arrive on its
own if we simply keep talking. I said in May that I preferred to see
concrete, actionable proposals before this went to Board, and I still think
that's right, but I'm aware that's easy to say and harder to act on, and
I've not done much acting on it myself.
To answer the question Goffi has now put twice: I don't think we're ready
for Board yet, and I want to be honest that this is the second time I've
said so. What I think would change that is a concrete proposal with the
prior art behind it. That's not far off (and the PR above already is a
small piece of it).
Kind regards,
Guus
On Wed, Jul 8, 2026 at 9:52=E2=80=AFAM Goffi <[email protected]> wrote:
> Hi,
>
> Le mardi 7 juillet 2026, 21:16:07 heure d=E2=80=99=C3=A9t=C3=A9 d=E2=80=
=99Europe centrale Ralph
> Meijer a =C3=A9crit :
>
> > [SNIP]
> > I do not see why these problems uniquely exist because of the use of AI=
,
> and why this isn't covered by an author's existing responsibility to ensu=
re
> quality and the pre-conditions for assigning ownership rights to the XSF
> per its IPR policy (in particular sections 3.1 and 3.2).
>
> The scale and effort required is not the same with AI.
>
> > If you cannot formulate the requirements for quality for humans, then
> how does declaring use of AI make things better? And if you can, and a
> submission complies, how does it matter that AI was used in the process?
> How would you handle =E2=80=9CAI-tainted=E2=80=9D submissions differently=
?
>
> I would read it differently. If I know that a whole section is AI written=
,
> I know that the text and references can be hallucinated, and that there c=
an
> be more boilerplate text than a human would do.
> If AI is used to extract table or make examples, I'll probably check
> quickly for hallucinated values.
> If AI is used for slight reformulation and spelling/grammar, I'll probabl=
y
> read it no differently as I read pure human submission.
>
> If a request is slop (low effort fully generated AI), I'll probably not
> bother and reject it.
>
> In any case, I would appreciate and consider polite to be informed if I'm
> reading a human or machine generated content.
>
> > The same holds for potential rights issues. The author is still
> responsible.
> >
> > My concern is that all future submissions will just have this disclosur=
e
> as boilerplate, and a recipient cannot assess how deep the impact of the
> use of AI is. With the accelerating growth we see in both the capabilitie=
s
> and the use of AI, this becomes increasingly hard. We will not have gaine=
d
> anything substantial. In that regard it reminds me of the Evil Bit (RFC
> 3514) / Malicious Stanzas (XEP-0076).
>
> This is not what I'm seeing in other projects. Even the local inference
> engine "llama.cpp", which we can hardly accuse to be "anti-AI", ask for
> that, you can check PRs there: https://github.com/ggml-org/llama.cpp/pull=
s
>
> >
> > The statement you linked to seems like common sense and doesn't actuall=
y
> require disclosure. Consider this document again, but conceptually replac=
e
> =E2=80=9Cthe use of AI=E2=80=9D with the =E2=80=9Cuse of a keyboard=E2=80=
=9D. Does having such a statement
> change the outcome of our standards process?
>
> This is a very poor comparison. It's like saying "I don't see why we need
> a driving license, I don't need one to walk". The scale is not the same,
> with LLM you can generate easily tons of text looking on the surface more
> or less OK.
>
> > I think that our author guidelines (XEP-0143) are already clear, and
> sense all the above boils down to this:
> >
> > =E2=80=9CAuthors must understand, verify, and take responsibility f=
or every
> contribution they submit.=E2=80=9D (-- ChatGPT with my prompting)
> >
> > While noting that this stance is not universally accepted (e.g. see <
> https://jme.bmj.com/content/51/4/230>), I think it is suitable for our
> standards process. Feel free to use this phrase in a concrete proposal,
> like a PR to XEP-0143.
>
> To clarify my (current) position: I'm not asking for an AI ban, it could
> not be enforceable and AI is a great tool for accessibility and many othe=
r
> things. But I'm advocating for requesting a disclosure (maybe not
> mandatory, but strongly suggested). Explain that we have human reviewers
> behind, and that we'll reject AI slops specifications. Use of AI need to =
be
> fully checked, and text should be reduced to essential. The later is one =
of
> the main painful point with content generated by or with AI: it's longer
> than necessary, and that make it harder to review.
>
> We could start to have this as a template/popup when doing a pull-request=
.
>
> > Disclosure: this message was manually (glide) typed on a OnePlus 12,
> using Google Board, in Thunderbird for Android. Conversing with AI may ha=
ve
> influenced my thought process. Except where explicitly noted, no excerpts
> of other works were included in this message.
>
> No need to be sarcastic here, this is a problem seen across the whole
> industry, it seems legitimate to me to state our position, like many othe=
r
> organisations are doing.
>
>
> Best,
> Goffi_______________________________________________
> Standards mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
--0000000000003da96b065615cd27
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi all,<br><br>Some thoughts, having read the thread throu=
gh again.<br><br>On disclosure: I understand the appeal. Mattj puts the str=
ongest version of the case: that we're currently in the dark about how =
these tools are being used in our community. My hesitation is with making i=
t a requirement. A requirement will mostly be honoured by people who aren&#=
39;t producing the submissions we broadly agree we want to stop, while the =
people producing those are unlikely to honour it. Without assignable conseq=
uences it doesn't bite, and my worry is that it mainly burdens contribu=
tors who are making perfectly good use of these tools. Goffi points to llam=
a.cpp and CPython. I don't know enough about how those requirements wor=
k in practice to say whether they transfer here. Both, I suppose, are handl=
ing code contributions with automated test suites behind them, which is may=
be a rather different review problem to ours?<br><br>One thing I think we s=
hould do regardless: Ralph proposed a sentence for XEP-0143, that authors m=
ust understand, verify, and take responsibility for every contribution they=
submit. That seems worth having written down whatever else we decide, so I=
've opened a PR for it: <a href=3D"https://github.com/xsf/xeps/pull/155=
2">https://github.com/xsf/xeps/pull/1552</a>. It is deliberately not AI-spe=
cific, and is not intended to settle anything else in this thread.<br><br>W=
hich brings me to what I think is the actual problem. One of the XSF's =
most valuable assets is the volunteering force that helps us achieve our go=
als. We have not historically done a great job at preventing burnout among =
those volunteers, and we need to do better. If we do start receiving large =
volumes of AI-generated slop (and I don't think that has happened yet, =
but we would be wise to prepare) it carries a significant risk of adding to=
those burdens. Kev's point about the Editor role, and about the effort=
asymmetry between generating and reviewing a submission, seems to me the c=
oncrete harm we should be organising around. Not copyright, and not disclos=
ure for its own sake.<br><br>So rather than "disclose AI", I'=
d like us to think about what we actually need in order to identify and han=
dle low-quality submissions at volume, whatever produced them, AI or humans=
. Two things I think we need in order to have that conversation properly:<b=
r><br>First, prior art. Goffi, you're the one with the most energy on t=
his and you're seeing it from the Council side. Would you be willing to=
take this on? Kev hinted at the GSoC mentor discussions this year, and the=
IETF has apparently seen entire suites of AI-generated Internet Drafts. Ot=
her organisations are dealing with this right now, and I'd like to know=
what they've tried and how it worked out before we invent our own appr=
oach. It's well-bounded work, and if it comes back showing that disclos=
ure requirements are doing real work elsewhere, that's an argument I=
9;d want to hear and one that would carry weight with Board.<br><br>Second,=
procedure. If we identify a submission as slop, what happens? I think we n=
eed to guard in two directions at once: against volunteers having to proces=
s slop, and against submitters being rejected bluntly ("computer says =
no").<br><br>MSavoritias made a point earlier: consensus is unlikely t=
o arrive on its own if we simply keep talking. I said in May that I preferr=
ed to see concrete, actionable proposals before this went to Board, and I s=
till think that's right, but I'm aware that's easy to say and h=
arder to act on, and I've not done much acting on it myself.<br><br>To =
answer the question Goffi has now put twice: I don't think we're re=
ady for Board yet, and I want to be honest that this is the second time I&#=
39;ve said so. What I think would change that is a concrete proposal with t=
he prior art behind it. That's not far off (and the PR above already is=
a small piece of it).<br><br>Kind regards,<br><div><br></div><div>=C2=A0 G=
uus</div></div><br><div class=3D"gmail_quote gmail_quote_container"><div di=
r=3D"ltr" class=3D"gmail_attr">On Wed, Jul 8, 2026 at 9:52=E2=80=AFAM Goffi=
<<a href=3D"mailto:[email protected]">[email protected]</a>> wrote:<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
Le mardi 7 juillet 2026, 21:16:07 heure d=E2=80=99=C3=A9t=C3=A9 d=E2=80=99E=
urope centrale Ralph Meijer a =C3=A9crit :<br>
<br>
> [SNIP]<br>
> I do not see why these problems uniquely exist because of the use of A=
I, and why this isn't covered by an author's existing responsibilit=
y to ensure quality and the pre-conditions for assigning ownership rights t=
o the XSF per its IPR policy (in particular sections 3.1 and 3.2).<br>
<br>
The scale and effort required is not the same with AI.<br>
<br>
> If you cannot formulate the requirements for quality for humans, then =
how does declaring use of AI make things better? And if you can, and a subm=
ission complies, how does it matter that AI was used in the process? How wo=
uld you handle =E2=80=9CAI-tainted=E2=80=9D submissions differently?<br>
<br>
I would read it differently. If I know that a whole section is AI written, =
I know that the text and references can be hallucinated, and that there can=
be more boilerplate text than a human would do. <br>
If AI is used to extract table or make examples, I'll probably check qu=
ickly for hallucinated values.<br>
If AI is used for slight reformulation and spelling/grammar, I'll proba=
bly read it no differently as I read pure human submission.<br>
<br>
If a request is slop (low effort fully generated AI), I'll probably not=
bother and reject it.<br>
<br>
In any case, I would appreciate and consider polite to be informed if I'=
;m reading a human or machine generated content.<br>
<br>
> The same holds for potential rights issues. The author is still respon=
sible. <br>
> <br>
> My concern is that all future submissions will just have this disclosu=
re as boilerplate, and a recipient cannot assess how deep the impact of the=
use of AI is. With the accelerating growth we see in both the capabilities=
and the use of AI, this becomes increasingly hard. We will not have gained=
anything substantial. In that regard it reminds me of the Evil Bit (RFC 35=
14) / Malicious Stanzas (XEP-0076).<br>
<br>
This is not what I'm seeing in other projects. Even the local inference=
engine "llama.cpp", which we can hardly accuse to be "anti-=
AI", ask for that, you can check PRs there: <a href=3D"https://github.=
com/ggml-org/llama.cpp/pulls" rel=3D"noreferrer" target=3D"_blank">https://=
github.com/ggml-org/llama.cpp/pulls</a><br>
<br>
> <br>
> The statement you linked to seems like common sense and doesn't ac=
tually require disclosure. Consider this document again, but conceptually r=
eplace =E2=80=9Cthe use of AI=E2=80=9D with the =E2=80=9Cuse of a keyboard=
=E2=80=9D. Does having such a statement change the outcome of our standards=
process?<br>
<br>
This is a very poor comparison. It's like saying "I don't see =
why we need a driving license, I don't need one to walk". The scal=
e is not the same, with LLM you can generate easily tons of text looking on=
the surface more or less OK.<br>
<br>
> I think that our author guidelines (XEP-0143) are already clear, and s=
ense all the above boils down to this:<br>
> <br>
>=C2=A0 =C2=A0 =C2=A0=E2=80=9CAuthors must understand, verify, and take =
responsibility for every contribution they submit.=E2=80=9D (-- ChatGPT wit=
h my prompting)<br>
> <br>
> While noting that this stance is not universally accepted (e.g. see &l=
t;<a href=3D"https://jme.bmj.com/content/51/4/230" rel=3D"noreferrer" targe=
t=3D"_blank">https://jme.bmj.com/content/51/4/230</a>>), I think it is s=
uitable for our standards process. Feel free to use this phrase in a concre=
te proposal, like a PR to XEP-0143.<br>
<br>
To clarify my (current) position: I'm not asking for an AI ban, it coul=
d not be enforceable and AI is a great tool for accessibility and many othe=
r things. But I'm advocating for requesting a disclosure (maybe not man=
datory, but strongly suggested). Explain that we have human reviewers behin=
d, and that we'll reject AI slops specifications. Use of AI need to be =
fully checked, and text should be reduced to essential. The later is one of=
the main painful point with content generated by or with AI: it's long=
er than necessary, and that make it harder to review.<br>
<br>
We could start to have this as a template/popup when doing a pull-request.<=
br>
<br>
> Disclosure: this message was manually (glide) typed on a OnePlus 12, u=
sing Google Board, in Thunderbird for Android. Conversing with AI may have =
influenced my thought process. Except where explicitly noted, no excerpts o=
f other works were included in this message.<br>
<br>
No need to be sarcastic here, this is a problem seen across the whole indus=
try, it seems legitimate to me to state our position, like many other organ=
isations are doing.<br>
<br>
<br>
Best,<br>
Goffi_______________________________________________<br>
Standards mailing list -- <a href=3D"mailto:[email protected]" target=3D"_=
blank">[email protected]</a><br>
To unsubscribe send an email to <a href=3D"mailto:[email protected]"=
target=3D"_blank">[email protected]</a><br>
</blockquote></div>
--0000000000003da96b065615cd27--
--===============7053063961094549560==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]
--===============7053063961094549560==--