Resumo

  • Datado de 5 de setembro de 2026, draft-das-eu-ai-act-execution-enforcement-00 é um Internet-Draft individual ativo de Sangam Das, com status pretendido Informational. Não é padrão do IETF nem avaliação regulatória.
  • O modelo transforma uma operação consequente em Candidate Act não efetivo, valida restrições já definidas, emite autoridade vinculada ao ato e exige nova verificação no Finality Sink antes do primeiro efeito externo protegido.
  • A seção 35 diz que a propriedade vale somente para efeitos mediados pela fronteira. Uma API externa direta em paralelo ao sink permanece explicitamente fora da proteção.
  • O código Python v0.1.0 demonstra uma fronteira local única de gravação de efeitos. Tanto o draft quanto o repositório recusam qualquer alegação de produto de segurança pronto ou mecanismo jurídico de conformidade.
  • Uma alegação sistêmica precisa de recibo de fechamento da superfície de efeito: todas as rotas, suas versões e controles, credenciais de desvio, exceções e testes negativos por caminho.

A pergunta anterior à criptografia

O desenho separa o que uma IA consegue calcular daquilo que pode tornar real. O sistema prepara um pagamento, mensagem, publicação, escrita ou comando, mas esse resultado permanece como Candidate Act. Uma função protegida avalia condições legíveis por máquina decididas fora do protocolo. Se forem satisfeitas, surge uma autoridade estreita, ligada ao conteúdo, destino, época de política, validade e sink. Na fronteira final, há nova conferência de digest, assinatura, revogação, consumo, prova de posse e estado atual.

Esse encadeamento evita que identidade vire autorização geral. Uma carga autenticada não ganha permissão para qualquer ato. Uma aprovação de valor ou destinatário não sobrevive a uma alteração. Um log posterior não impede a consequência.

Mas a seção de segurança mostra uma bifurcação: do AI Agent sai um ramo para o Finality Sink e outro para uma direct external API. O texto conclui que a API direta não recebeu proteção de finalização. O componente pode funcionar perfeitamente e ainda ser opcional.

Pense em um gateway de pagamentos protegido enquanto uma conta de serviço chama o endpoint de liquidação; em uma interface editorial controlada enquanto uma credencial grava direto no armazenamento público; ou em um proxy de banco de dados acompanhado de uma conexão de contingência. São hipóteses de arquitetura, não relatos de incidentes. Elas revelam que a unidade da promessa é a superfície de efeito.

Selecionar consequências exige fechar seus caminhos

O draft não manda passar cada token, leitura e pacote pelo sink. Ele fala em transições consequentes selecionadas. Isso evita uma camada central desnecessária sobre toda computação. O ponto comum mínimo pode ficar no momento em que dinheiro sai, uma mensagem é transmitida, uma linha é confirmada, um arquivo é liberado ou um atuador recebe comando.

Contudo, selecionar uma consequência não permite selecionar apenas a rota mais visível. Se duas interfaces produzem o mesmo efeito, ambas entram no escopo ou uma aparece como exceção. Fallback, lote, migração, SDK, credencial administrativa e serviço destinatário contam. “Fora do diagrama” não significa “fora da capacidade”.

O local da observação também importa. O draft admite que validação local não torna atômica uma requisição arbitrária pela Internet. Efeitos remotos podem depender de sink no destinatário, idempotência, outbox transacional ou coordenação de estados. Portanto, o teste negativo precisa chegar ao primeiro estado externo utilizável.

O alcance real da referência

A versão 0.1.0 usa representação canônica, SHA-256, Ed25519, prova de posse, época de política, nonce e SQLite. No exemplo sintético de atendimento, uma troca indevida de finalidade é negada antes de se registrar o efeito.

O README explica por que: a única API de gravação de efeito está dentro do sink. Em uma implantação real, egresso de rede, commit de dados, submissão de pagamento, exportação de arquivo, invocação de ferramenta e demais caminhos precisam de mediação equivalente.

É uma demonstração útil e limitada. Não há garantia de HSM ou TEE de produção, consenso distribuído, PKI completa, verificação formal, alta disponibilidade, proteção contra canais laterais, atomicidade remota integral ou conformidade regulatória. A separação lógica num processo Python também não impede acesso por um administrador irrestrito do processo.

Fechamento verificável

O recibo proposto começa pelo efeito: qual estado se torna utilizável, onde e para quem. Em seguida inventaria gateways, filas, conexões, SDKs, armazenamento, rede, nuvem, receptor e caminhos de emergência. Cada rota recebe uma fronteira protegida, identidade do sink, versão de rota e política, credenciais e responsáveis.

Depois vêm testes de autoridade ausente, vencida, revogada, repetida, alterada, vinculada ao sink errado ou acompanhada de prova de carga inválida. Aprovação significa nenhum efeito em todas as rotas listadas. Caminho não testado fica como desconhecido; exceção intencional expõe sua autoridade e reduz a abrangência da promessa.

Esse recibo é recomendação de Daniel Kade. Não é texto do IETF, da União Europeia ou de Sangam Das. Ele tampouco decide se a restrição codifica corretamente a lei. O draft deixa classificação de risco, práticas proibidas, suficiência de supervisão humana e conformidade geral fora do protocolo. A prova é apenas de inevitabilidade técnica dentro de um efeito e uma topologia declarados.

O possível trabalho de padronização também é menor que o título jurídico: representação do ato, canonicalização, evidência, autorização vinculada, prova de posse, ligação ao sink, vigência, revogação e erros. Pela disciplina de código em execução de Heng Lu, uma conformidade de componente nunca deve crescer silenciosamente até virar certeza sobre todo o sistema.

Um Finality Sink bloqueia o ato inválido que recebe. Não bloqueia o ato enviado por outro caminho.

Fontes