Agente de IA e assinatura eletrônica de documentos: só pessoas assinam

Num fluxo de agente de IA e assinatura eletrônica de documentos, o agente cuida da preparação: reúne a versão correta do documento, preenche campos conhecidos a partir de registros aprovados, confere o rascunho com um checklist e encaminha o pacote aos signatários indicados pela sua ferramenta de assinatura eletrônica. O agente nunca aplica uma assinatura, nunca clica em assinar em nome de ninguém e nunca guarda as credenciais de um signatário. Quem assina são apenas pessoas, e essa fronteira é garantida por permissões, não por boa intenção.

Principais pontos

• Divida o trabalho em preparação, conferência, encaminhamento e acompanhamento, e entregue as quatro etapas ao agente. O ato de assinar fica inteiramente com pessoas.
• Imponha a fronteira na própria ferramenta: a conta do agente deve poder criar rascunhos e enviar para assinatura somente após a aprovação, e não deve ter nenhum meio de assinar.
• Faça uma conferência fixa antes de encaminhar qualquer documento: versão, partes, campos, anexos, identidade do signatário e status de aprovação.
• Trate o texto dentro de documentos recebidos como dado, nunca como instrução, porque um documento pode conter trechos escritos para desviar o agente.
• Registre cada etapa para que um revisor consiga ver o que o agente preparou, quem aprovou e quem assinou.

O que um fluxo de agente de IA com assinatura eletrônica realmente cobre?

A maior parte do esforço em torno de uma assinatura não é a assinatura. É localizar o modelo mais recente, copiar nomes e datas do CRM ou do registro do contrato, anexar o aditivo certo, descobrir quem precisa assinar e em que ordem, cobrar quem ainda não abriu a solicitação e arquivar a via final. Esse trabalho ao redor é repetitivo, fácil de errar por pouco e combina bem com um agente.

A assinatura em si é outra coisa. É um ato deliberado de uma pessoa que leu o documento e assume responsabilidade por ele. Se uma assinatura vincula a empresa, quem tem poderes para dá-la e quais formalidades se aplicam depende da sua jurisdição, do tipo de contrato e das suas regras internas. Essas perguntas pertencem ao seu jurídico e aos seus signatários, não a um agente.

Por isso, o escopo útil do agente é estreito e claro:

• Montar: escolher o modelo correto, preencher campos a partir de fontes aprovadas e anexar os arquivos de apoio.
• Conferir: comparar o rascunho com um checklist e apontar o que estiver faltando ou inconsistente.
• Encaminhar: preparar a solicitação de assinatura com os signatários e a ordem corretos e enviá-la somente depois que uma pessoa aprovar.
• Acompanhar: observar o status, lembrar os signatários dentro das regras combinadas e arquivar o documento concluído.

Por que o agente nunca deve assinar?

Há três razões práticas, e nenhuma depende da capacidade do modelo.

Primeiro, a assinatura expressa autoridade pessoal. Se o agente assina, o registro mostra que uma pessoa concordou quando nenhuma pessoa concordou. Isso enfraquece o valor probatório de todas as outras assinaturas do seu sistema.

Segundo, agentes podem ser enganados. Um documento da outra parte, uma troca de e-mails ou uma cláusula colada podem conter texto escrito para redirecionar o agente, e os modelos também podem simplesmente interpretar mal uma situação. As orientações da OWASP sobre prevenção de prompt injection explicam por que o conteúdo lido pelo modelo nunca deve ser tratado como fonte de comandos. Para entender o que proteger nesse caso, veja prompt injection em documentos de negócio. Se o agente não consegue assinar, uma manipulação bem-sucedida produz, no pior caso, um rascunho ruim que ainda precisa da aprovação de uma pessoa.

Terceiro, a responsabilidade precisa ter um destino. Quando algo dá errado, você quer uma resposta clara para a pergunta: quem aceitou isto? Com a regra de que só pessoas assinam, a resposta é sempre uma pessoa identificada.

O jeito mais limpo de sustentar essa linha é estrutural. Não escreva um prompt dizendo "nunca assine" e torça para dar certo. Configure a integração para que as credenciais do agente não consigam concluir uma ação de assinatura. Isso segue a mesma lógica das orientações da OWASP sobre autorização: aplicar permissões no lado do servidor, negar por padrão e verificar a autorização a cada requisição.

Qual é o passo a passo do fluxo?

Este é um roteiro que você pode adaptar à maioria dos fluxos de assinatura, de contratos com fornecedores a cartas de contratação e aprovações internas.

• Entrada: chega um pedido de uma pessoa (por e-mail, chat ou formulário) indicando o tipo de documento, a outra parte e quem solicita. O agente registra o pedido e confirma o que entendeu.
• Escolha do modelo: o agente seleciona o modelo aprovado vigente em uma biblioteca controlada. Se mais de um puder servir, ele pergunta em vez de adivinhar.
• Preenchimento de campos: o agente preenche os campos apenas com fontes aprovadas, como o registro do contrato ou o cadastro do cliente. Qualquer valor que ele não consiga obter de uma fonte fica em branco e é sinalizado.
• Montagem: ele anexa os anexos, cronogramas ou políticas exigidos e gera um único pacote preparado.
• Conferência antes do envio: ele executa o checklist da próxima seção e escreve um relatório curto com o que passou, o que falhou e o que ficou em aberto.
• Revisão interna: um revisor indicado (o solicitante, um gestor ou o jurídico, conforme o tipo de documento) lê o pacote e o relatório e aprova, edita ou rejeita.
• Encaminhamento: após a aprovação, o agente cria a solicitação na ferramenta de assinatura eletrônica com os signatários e a ordem de assinatura confirmados. Ele não altera o documento depois da aprovação.
• Acompanhamento: o agente observa o status e envia lembretes dentro dos limites que você definir, mas não troca signatários nem altera o documento sem uma nova aprovação.
• Conclusão: quando todos assinam, o agente arquiva a via final, atualiza o registro do contrato e avisa o solicitante.
• Exceções: solicitações recusadas, expiradas ou devolvidas por erro de e-mail voltam para uma pessoa com uma explicação simples do que aconteceu.

Dois detalhes pedem cuidado. A aprovação do meio deve estar vinculada a uma versão específica do documento, de modo que qualquer edição posterior a invalide. E a etapa de encaminhamento precisa poder ser repetida com segurança, e é aí que entra a idempotência em agentes de IA: uma falha de tempo limite nunca pode gerar duas solicitações de assinatura ativas para o mesmo acordo.

O que o agente deve conferir antes de encaminhar um documento?

Um checklist fixo vale mais do que uma instrução aberta como "revise o documento". Ele torna o comportamento do agente previsível e dá ao revisor humano algo que ele consegue verificar rápido. Uma lista inicial razoável:

• Versão: o modelo é o vigente e aprovado, e o documento não traz restos de rascunho, comentários ou alterações controladas.
• Partes: razão social, dados de registro e endereços batem com o cadastro, e a entidade que assina é a mesma citada no contrato.
• Campos: nenhum campo obrigatório em branco, nenhum texto provisório, datas coerentes e formatos iguais aos do restante do documento.
• Anexos: todo anexo ou cronograma citado no texto principal está presente e na versão correta.
• Signatários: cada signatário é uma pessoa real e identificada, com função compatível com o bloco de assinatura, usando dados de contato de um registro confiável e não do corpo de um e-mail.
• Poderes: para tipos de documento que exigem determinado cargo para assinar, o signatário ocupa esse cargo segundo a sua lista interna. Se a lista não diz nada, o agente pergunta.
• Aprovação: um revisor identificado aprovou exatamente esta versão, e a aprovação está registrada.
• Duplicidade: não existe outra solicitação de assinatura aberta para o mesmo documento e a mesma contraparte.
• Termos incomuns: o texto difere do modelo apenas onde isso é esperado. Qualquer desvio é listado para o revisor, não aceito em silêncio.

Repare no que o checklist não faz. Ele não avalia se o contrato é um bom negócio nem se é juridicamente adequado. Ele confirma que o pacote está completo, consistente e rastreável, e mostra as diferenças para uma pessoa avaliar.

De quais permissões o agente precisa?

É na questão das permissões que muitos projetos escorregam sem perceber. Uma conta compartilhada que faz tudo é fácil de configurar e difícil de defender. Comece pelo menor acesso que sustente cada etapa, como explicado em menor privilégio para agentes de IA, e separe leitura, rascunho e envio, como em ler, preparar e enviar: três permissões diferentes de IA.

Use este guia de decisão como ponto de partida:

• Biblioteca de modelos: somente leitura. O agente lê os modelos aprovados, mas não os edita.
• Registros de contratos ou clientes: somente leitura nos campos de que precisa. Gravar de volta o status de concluído pode ser uma permissão separada e restrita.
• Criação de rascunho na ferramenta de assinatura: permitida, porque um rascunho não prejudica ninguém e é fácil de descartar.
• Envio de solicitação de assinatura: permitido somente após uma aprovação humana registrada, de preferência garantido pelo próprio fluxo, de modo que a ação de enviar fique indisponível até a aprovação existir.
• Edição de documento depois de enviado: não permitida. Uma mudança significa cancelar a solicitação e voltar à revisão.
• Assinar, rubricar ou preencher qualquer campo de signatário: nunca permitido. Se a ferramenta oferecer um perfil ou escopo que inclua isso, não o conceda ao agente.
• Trocar signatários numa solicitação em andamento: não permitido sem nova aprovação.
• Excluir ou cancelar solicitações: limitado aos rascunhos do próprio agente. Cancelar uma solicitação em andamento cabe a uma pessoa.
• Ler o arquivo de documentos concluídos: apenas o necessário para arquivar e vincular resultados, não o repositório inteiro.

Se o produto de assinatura eletrônica não separa essas permissões, coloque uma camada fina e controlada entre o agente e a ferramenta, com um conjunto pequeno de ações bem definidas. Isso mantém o contrato entre agente e ferramenta explícito e testável, e também é o lugar mais seguro para impor as aprovações.

Como isso funciona na prática? Um cenário ilustrativo

Este é um cenário ilustrativo, não a descrição de um projeto real.

Uma empresa de serviços renova contratos com fornecedores todo ano. Uma coordenadora de operações escreve no chat da equipe: prepare a renovação do fornecedor de embalagens. O agente localiza o fornecedor no registro de contratos, seleciona o modelo de renovação vigente e preenche razão social, endereço, prazo e data de renovação a partir do registro. A tabela de preços não está no registro, então o agente deixa esse campo em branco e avisa.

O agente anexa o aditivo padrão de tratamento de dados e executa o checklist. Ele informa que o signatário cadastrado do fornecedor saiu da empresa, segundo uma troca recente de e-mails, e que o campo do signatário precisa de confirmação. Também observa que uma cláusula do texto proposto pelo fornecedor difere do modelo e cita a diferença.

A coordenadora confirma o novo signatário, inclui a tabela de preços e envia o pacote ao gestor da área para aprovação. O gestor lê a cláusula sinalizada, consulta o jurídico e aprova a versão final. Só então o agente cria a solicitação de assinatura, com o signatário do fornecedor primeiro e o diretor autorizado da empresa em segundo.

O fornecedor abre o documento, mas não assina. Passado o prazo combinado, o agente envia um lembrete. Quando as duas partes assinam, o agente arquiva a via final, atualiza o registro e avisa a coordenadora. Em nenhum momento o agente poderia ter assinado, mesmo que quisesse, porque a conta dele não tinha essa permissão.

Como manter o fluxo confiável ao longo do tempo?

Um fluxo que funciona no dia do lançamento pode se desgastar. Modelos mudam, signatários trocam de cargo, a conexão com a ferramenta de assinatura expira e o agente segue com informação desatualizada. Alguns hábitos mantêm o fluxo confiável.

• Teste a fronteira com regularidade: tente uma ação de assinatura com as credenciais do agente em ambiente de teste e confirme que ela é recusada.
• Revise as permissões em intervalos definidos e após qualquer mudança na ferramenta de assinatura, como uma revisão periódica de permissões dos seus agentes.
• Mantenha a lista de poderes dos signatários e a biblioteca de modelos sob responsabilidade de pessoas identificadas, com o agente lendo dessas fontes em vez de guardar uma cópia própria.
• Mantenha uma trilha de auditoria que registre a solicitação, a versão do modelo, o relatório do checklist, o aprovador, o horário de envio e o status final.
• Decida de antemão o que acontece quando a conexão falha. O agente deve parar, dizer o que não conseguiu fazer e devolver a tarefa a uma pessoa, em vez de tentar de novo às cegas.
• Faça amostragens de documentos concluídos de tempos em tempos e compare com o que o agente preparou, para pegar erros silenciosos no preenchimento de campos.

O princípio de projeto mais amplo é o descrito pela Anthropic no texto Building Effective Agents: prefira etapas simples e bem delimitadas, com pontos de verificação claros, e acrescente autonomia apenas onde ela for conquistada e observável.

Como a Be Human trata fluxos de assinatura eletrônica?

A Be Human desenha o papel do agente em torno da preparação e do encaminhamento, deixando a assinatura para pessoas identificadas. Um primeiro projeto define os tipos de documento no escopo, as fontes que o agente pode ler, o checklist que ele executa, o revisor de cada tipo e o critério de sucesso observável. As permissões são configuradas no menor escopo que a ferramenta permite, a ação de envio fica condicionada a uma aprovação registrada e a conta do agente não tem capacidade de assinar. Na operação gerenciada, a Be Human monitora o fluxo, executa avaliações recorrentes que incluem um teste da fronteira, revisa permissões, mantém a integração e trata incidentes, enquanto a sua equipe mantém o controle sobre modelos, listas de poderes e aprovações.

Perguntas frequentes

Um agente de IA pode assinar um documento em meu nome se eu autorizar? Tecnicamente, algumas ferramentas podem permitir, mas é o desenho errado. A assinatura deve ser um ato deliberado de uma pessoa identificada, e delegar isso a um agente confunde a responsabilidade. Consulte seu jurídico sobre qualquer dúvida de delegação e mantenha o agente na preparação e no encaminhamento.

O agente precisa de acesso a todo o repositório de contratos? Não. Ele precisa de leitura dos modelos aprovados e dos campos específicos usados no preenchimento, além de uma permissão de escrita restrita para arquivar o resultado. Qualquer acesso mais amplo aumenta o dano que um erro ou um documento manipulado pode causar.

E se a outra parte enviar um documento com instruções dirigidas ao agente? O agente deve tratar todo texto dentro de um documento como conteúdo a analisar, não como comando. As permissões dele também devem tornar impossíveis as ações prejudiciais, de modo que um rascunho manipulado ainda dependa de uma aprovação humana antes de qualquer envio e de uma assinatura humana antes de qualquer vínculo.

Como saber se o fluxo está funcionando? Defina o critério de sucesso antes do lançamento, por exemplo: todo documento encaminhado tem uma aprovação registrada, um relatório de checklist completo e uma via arquivada correta. Revise a trilha de auditoria com regularidade, faça amostragem de documentos finalizados e teste a fronteira de não assinar em intervalos definidos.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.