Resumo

  • draft-fengfar-led-01 recomenda formar uma posição antes de usar IA, revisar a fidelidade da saída e ser sempre transparente, mas continua sendo um Internet-Draft individual ativo, não uma política do IETF.
  • O escopo inclui e-mail, slides, discussões em repositórios e possivelmente mensagens instantâneas. O texto dentro de Internet-Drafts e RFCs fica expressamente fora porque também envolve BCP 78 e BCP 79.
  • Uma divulgação útil deve acompanhar a contribuição e registrar pessoa responsável, função e escopo da ferramenta, fronteira do material, verificações, aprovação final, capacidade de envio autônomo e caminho de correção.

O rótulo fica; o contexto desaparece

Arquivos de padrões são longos. Uma mensagem escrita hoje pode ser citada muito depois de o modelo, a interface e até a política terem mudado. Nesse ambiente, “usei IA” é um registro durável de baixa informação.

O aviso não diz se a ferramenta traduziu uma posição já decidida, recuperou uma discussão antiga, resumiu um consenso, escreveu uma seção, forneceu uma alegação não verificada ou enviou a mensagem sem uma última decisão humana. Também não mostra que parte do texto foi afetada nem quais fontes foram conferidas.

O Internet-Draft draft-fengfar-led-01 formula a orientação mais curta como “Always be transparent”. O próprio documento reconhece que isso ainda não é operacional. Chama as recomendações concretas de extremamente provisórias e conclui que é cedo demais para fechar a questão. A proposta mais firme é que o IETF desenvolva orientação antes que a confiança na discussão por e-mail se deteriore.

O estado formal é decisivo. O Datatracker registra o texto como um Internet-Draft individual ativo, em I-D Exists, sem stream de RFC, Area Director responsável ou data de telechat. A mensagem de 31 de julho que iniciou o debate o descreveu como preliminar, não prescritivo e sem autoridade. A versão 01, de 6 de agosto, incorporou pontos da lista geral. Isso não equivale a adoção por Working Group, rough consensus, aprovação do IESG ou regra do IETF.

Em 26 de agosto, um artigo de George Michaelson no APNIC Blog ampliou a atenção ao relacionar IA e o custo de participar em inglês na elaboração de padrões e políticas de RIR. A página informa que as opiniões do autor não representam necessariamente a APNIC. A notícia é a ampliação da discussão, não a adoção de uma política por qualquer uma das instituições.

O limite de escopo protege duas conversas diferentes

O rascunho trata de texto usado em discussões do IETF: mensagens de lista, slides de reunião, issues e pull requests no GitHub e, talvez, mensagens instantâneas. Ele exclui explicitamente o conteúdo de Internet-Drafts e RFCs, que encontra também as regras de contribuição e propriedade intelectual de BCP 78 e BCP 79.

Esse limite impede uma conclusão apressada. Uma futura orientação para e-mail não decidiria automaticamente autoria e divulgação no corpo de um documento de padrões. Uma nota de agradecimento num Internet-Draft, por sua vez, não explica se as mensagens que construíram a discussão foram traduzidas, resumidas, geradas ou publicadas por agentes.

A origem do texto mostra a lacuna. Um participante usou IA para expressar melhor ideias formadas de modo independente. Um leitor percebeu uma voz semelhante à de LLM e desistiu porque não conseguia delimitar a contribuição humana. Os autores preservam os dois pontos de vista, em vez de declarar culpado ou inocente.

O limite humano proposto é razoável: formar a posição primeiro, conferir a fidelidade da saída à posição real e assumir responsabilidade total pelo que é enviado. Mas responsabilidade como princípio não é o mesmo que responsabilidade registrada junto ao objeto que permanece no arquivo.

A redução de uma barreira pode criar outra carga

Assistência de tradução e edição pode ampliar a participação. Ter uma boa ideia técnica não garante ter o mesmo domínio do inglês. Ferramentas podem deslocar esforço da superfície linguística para o problema de engenharia.

Também podem deslocar esforço do remetente para todos os leitores. Uma resposta polida e abrangente pode ser produzida mais rápido do que a comunidade consegue checar fatos, localizar a divergência real e saber se uma pessoa compreende a afirmação. Agentes respondendo a agentes podem gerar a aparência de atenção coletiva sem julgamento independente.

O rascunho registra preocupações com paredes de texto, excesso de confiança e mudança de voz. Nenhum desses sinais é procedência. Inglês fluente, velocidade ou pontuação de detector são inferências e atingiriam de forma previsível quem escreve numa segunda língua ou usa tecnologia assistiva.

Uma declaração atribuível também não torna o argumento correto. Procedência ajuda a localizar responsabilidade; revisão técnica determina validade. Confundir os dois controles criaria uma licença de fala para conteúdo rotulado e uma presunção de fraude para conteúdo sem rótulo.

Três vizinhos, três autoridades

RFC 9775 oferece uma regra próxima no IRTF. O documento representa consenso do IRSG e afirma expressamente que não é produto do IETF nem padrão. Em seu domínio, IA generativa não pode figurar como autora. Quantidades significativas de texto ou outro conteúdo gerado precisam ser divulgadas, por exemplo com o sistema e sua contribuição. Ortografia, gramática, tradução e apresentação não precisam.

Uma Group Note do Advisory Board do W3C, publicada em março de 2026, escolhe outro limiar: rótulo claro quando o conteúdo for principalmente saída de LLM. Também exige verificação, responsabilidade individual, proteção de informação confidencial e cuidado para que respostas automáticas não substituam deliberação. A nota é endossada pelo Advisory Board, não pelo W3C inteiro ou por seus membros.

“Quantidade significativa”, “principalmente saída” e “sempre transparente” são escolhas institucionais diferentes. Importar uma delas silenciosamente para o IETF apagaria a fronteira de autoridade que os próprios documentos publicam.

O registro de responsabilidade de Daniel Kade

A unidade mínima adequada é um registro associado a uma contribuição identificável.

Ele começa pelo remetente humano e um identificador estável. Depois classifica a função da ferramenta: tradução, edição, resumo, redação, recuperação, análise, código, assistência à moderação ou envio autônomo. A função é vinculada ao escopo: mensagem inteira, seção nomeada, anexo, trecho de código ou alegações específicas.

O registro descreve a fronteira do material: apenas fontes públicas, anotações locais ou conteúdo confidencial. Essa categoria não expõe o material. Transparência não deve exigir prompts completos, credenciais, notas privadas, rascunhos confidenciais, contexto proprietário ou cadeia de pensamento; isso criaria um novo incidente de segurança.

Em seguida vêm os atos humanos: fontes factuais e citações conferidas, revisão de fidelidade à posição real, aprovação final e existência de permissão para envio sem aprovação. O registro inclui versão e data da política e um caminho para corrigir ou substituir uma contribuição ou declaração errada.

O nome do modelo é contexto, não prova. O fornecedor pode mudar o comportamento mantendo o rótulo do produto; e o nome não demonstra compreensão de protocolo, conferência de citação ou aceitação de responsabilidade.

Esse desenho é uma proposta de Daniel Kade, não uma exigência do rascunho. Ele tenta preservar a decisão humana e tornar a execução da ferramenta visível o suficiente para auditoria.

Definir antes de aplicar sanções

RFC 9245 define a lista geral e inclui questões de direção, política e processo de padrões quando não há foro melhor. RFC 9945 distribui responsabilidades entre participantes, administradores, moderadores, Area Directors e IESG nos fóruns públicos. Limita ações de moderação a comunicação disruptiva e prevê procedimento público, reconsideração e recurso.

Nenhum deles cria detector de autoria por IA ou transforma suspeita estilística em infração autônoma. Se uma futura orientação chegar à moderação, a definição precisa vir antes da sanção: limiar, padrão de prova, aviso, correção e apelação. Caso contrário, uma acusação baseada em estilo ganha poder processual.

O rascunho recomenda perguntas não acusatórias e observa que participantes novos podem desconhecer uma regra, enquanto diferenças no acesso às ferramentas podem criar outra barreira. A sequência segura é estreita: definir função e escopo, testar o registro, medir se reduz carga e falsos positivos e só então decidir se a falta de divulgação é orientação, falha de processo ou conduta disruptiva.

O que não se pode concluir

O IETF não adotou nem rejeitou participação assistida por IA. Não há evidência de que conteúdo gerado tenha mudado um resultado real de consenso. O rascunho não torna obrigatória hoje a declaração de toda mensagem assistida.

RFC 9775 não governa automaticamente a discussão comum do IETF. A Group Note do W3C não representa consenso de seus membros. O texto do APNIC Blog não anuncia política da APNIC. O conjunto de evidências não mostra que uma pessoa específica tenha falseado autoria ou delegado envio autônomo.

A conclusão delimitada é que a discussão localizou corretamente o ser humano responsável, mas ainda não o registro que torna essa responsabilidade inspecionável. Transparência vira governança quando objeto, autoridade, verificação e correção ficam ligados.

Fontes

  1. https://datatracker.ietf.org/doc/draft-fengfar-led/
  2. https://www.ietf.org/archive/id/draft-fengfar-led-01.html
  3. https://mailarchive.ietf.org/arch/msg/ietf/3VaBJ6pEdhtkpOtnZYA_HcVHejU/
  4. https://mailarchive.ietf.org/arch/msg/i-d-announce/_nalEUgYdyn7LdNfwQghXW9dPRc/
  5. https://blog.apnic.net/2026/08/26/the-emerging-role-of-ai-in-governance-discussion/
  6. https://www.ietf.org/rfc/rfc9775.html
  7. https://www.w3.org/TR/2026/NOTE-llms-standards-20260324/
  8. https://datatracker.ietf.org/doc/html/rfc9245
  9. https://datatracker.ietf.org/doc/html/rfc9945
  10. https://datatracker.ietf.org/doc/html/rfc5378
  11. https://datatracker.ietf.org/doc/html/rfc8179