Casos de Uso

A Apollo consegue fazer o redline dos seus contratos? Sim, contra o seu playbook, cláusula por cláusula

Redlining não é ler um contrato. É avaliar cada cláusula contra os deals que você já acordou, sinalizar o termo fora-do-mercado, rascunhar a contraproposta, nomear o risco, e entregar a um humano a decisão.

ASR

Apollo Space Research

Apollo Space

· 13 min de leitura

O contrato de um fornecedor aterrissa na inbox às 16h de uma sexta. Vinte e duas páginas. Em algum lugar na cláusula 9.3 o limite de responsabilidade é um doze avos do que você assinou no trimestre passado, a renovação automática é silenciosa, e os termos de pagamento escorregaram discretamente de 60 dias para 15. Nada disso está sinalizado. Nada disso está errado, exatamente, é só o papel deles, escrito para favorecê-los, do jeito que todo primeiro rascunho é. O trabalho à sua frente não é lê-lo. É encontrar os três lugares onde ele discorda de como você faz negócios, e empurrar de volta em cada um antes de assinar.

Esse trabalho tem um nome. Chama-se redlining, e quase ninguém o faz bem, porque fazê-lo bem significa segurar todo o seu histórico de deals na cabeça de uma vez.

Redlining não é ler um contrato, é avaliar cada cláusula contra os deals que você já acordou, sinalizar o termo fora-do-mercado, rascunhar a contraproposta, e nomear o risco. Essa frase é o produto inteiro. O resto deste post a desmonta, cláusula por cláusula, e mostra por que a parte difícil nunca foi a leitura.

Ler um contrato não é o mesmo que fazer o redline de um

Comece com a confusão que afunda a maioria das ferramentas de “IA para jurídico”.

A versão ingênua lê o contrato e o resume. Você cola vinte e duas páginas e recebe de volta um parágrafo arrumado: este é um contrato de serviços de software, prazo de doze meses, com cláusulas padrão de responsabilidade e confidencialidade. Útil, brevemente. Depois inútil, porque um resumo te diz o que o contrato diz, e o ponto inteiro do redlining é pegar o que o contrato diz que você nunca aceitaria. Um resumo que chama a cláusula 9.3 de “responsabilidade padrão” já perdeu, porque 9.3 não é padrão. É um doze avos do seu limite normal, e “padrão” é exatamente a palavra que a deixa passar.

A dor aqui é específica, e qualquer um que já assinou um contrato de fornecedor sob pressão de tempo a conhece. O contrato é internamente coerente. Cada cláusula lê como razoável por conta própria. O termo fora-do-mercado não parece errado; parece normal, porque o outro lado o escreveu para parecer normal. Você pode ler tudo com cuidado, entender cada palavra, e ainda assim assinar um mau deal, porque o problema nunca foi compreensão. Foi comparação.

Redlining é comparação. Ele avalia cada cláusula não contra o dicionário mas contra uma baseline: os termos que você de fato acordou antes, o piso abaixo do qual você não desce, o playbook que seu negócio segue. “15 dias” não é ruim no abstrato. É ruim em relação aos 60 dias que você assinou onze vezes. A inteligência não está em entender a cláusula. Está em saber o que você considera que a cláusula deveria dizer, e em notar, instantaneamente, cada lugar onde este papel se desvia.

Então um sistema de redlining não pode começar com um leitor. Ele tem que começar com uma memória dos seus deals.

O playbook é a parte que ninguém consegue segurar na cabeça

Aqui está a coisa que faz do redlining um trabalho para software e não um prompt mais esperto.

Sua posição de negociação não está escrita num lugar só. Está espalhada por cada contrato que você já assinou. O limite de responsabilidade em que você segura a linha mora num deal de dois anos atrás. A linguagem de indenização que seu jurídico insiste mora num template que alguém salvou uma vez e esqueceu. O fato de que você sempre risca a cláusula de rescisão unilateral mora em lugar nenhum, mora no hábito de uma pessoa que negociou quarenta destes e simplesmente sabe. Quando essa pessoa está ocupada, ou de férias, ou foi embora, o playbook vai junto.

Então a correção ingênua é pedir a um generalista afiado para “revisar este contrato em busca de termos desfavoráveis”. E um generalista afiado vai pegar os óbvios, o limite de responsabilidade faltante, a indenização absurda. Mas “desfavorável” é relativo a uma baseline que o generalista não tem. Ele não sabe que você sempre limita em um múltiplo específico, que você nunca aceita renovação automática sem uma janela de aviso, que 30 dias é seu piso e 15 dias é um abandono. Ele sinaliza o que é incomum em geral. Ele não consegue sinalizar o que é incomum para você, porque a coisa que é incomum para você está codificada no seu histórico, e ele nunca o leu.

É aqui que um company brain muda a forma do problema. Suponha que o sistema tenha lido cada contrato que você assinou, não para resumi-los, mas para aprender a forma dos deals que você aceita. Os múltiplos de responsabilidade que você segurou. Os termos de pagamento em que você assentou. As cláusulas que você risca com confiabilidade. Isso não é um documento. É uma posição, destilada do seu próprio histórico, e é a coisa contra a qual o redline avalia. A cláusula não é comparada com algum “contrato justo” platônico. Ela é comparada com os contratos que têm a sua assinatura.

Um contrato de fornecedor é dividido em cláusulas, e cada cláusula é avaliada contra o playbook da empresa aprendido de deals assinados no passado; cláusulas que casam passam limpas, enquanto cláusulas que se desviam são sinalizadas com uma contraproposta rascunhada e um risco nomeado para um humano decidir.

Essa é a fundação. Uma vez que a posição existe, o redline são três jogadas em cada cláusula.

Jogada um: sinalize o termo que está fora do seu mercado

A primeira jogada é o corte. Vinte e duas páginas viram uma lista curta das cláusulas que discordam do seu playbook.

A versão ingênua sinaliza tudo e não ajuda em nada. Você já viu essa ferramenta, ela destaca quarenta passagens em amarelo, “para sua revisão”, e agora você tem uma revisão de quarenta itens em vez de um contrato. Isso não é triagem. É o mesmo problema num marca-texto. O custo de sinalizar tudo é idêntico ao custo de sinalizar nada: você ainda tem que ler tudo para achar as três que importam.

O trabalho é o corte, e o corte só é possível porque há uma baseline contra a qual cortar. O limite de responsabilidade casa com seu piso, passe, silenciosamente, sem sinalizar. A cláusula de confidencialidade é sua linguagem padrão, passe. Os termos de pagamento caíram para 15 dias contra seu histórico de 60, sinalize, porque se desvia. A renovação automática não tem janela de aviso onde você sempre exige uma, sinalize. Três sinalizações de vinte e duas cláusulas, e as outras dezenove avaliadas limpas e liberadas. A atenção do leitor vai para os três desvios, não para o documento inteiro, porque o sistema já comparou todas as vinte e duas e só guardou as que brigam com seu playbook.

Um bom redline é em sua maioria silêncio. Dezenove cláusulas que ele nunca menciona, porque dezenove cláusulas concordaram com você. O valor inteiro está no que ele não traz à tona.

Jogada dois: rascunhe a contraproposta, não só reclame

Sinalizar é metade de um trabalho. Uma sinalização que diz “este termo é desfavorável” te deixa exatamente onde você começou, você sabia que o contrato os favorecia; é por isso que é o contrato deles. A sinalização que merece seu lugar vem com o conserto já escrito.

Imagine a diferença. A versão fraca diz: cláusula 9.3 limita responsabilidade abaixo do seu limiar típico. Verdade, inútil, e agora você abre um documento em branco e escreve a contraproposta você mesmo às 17h de uma sexta. A versão forte diz: cláusula 9.3 limita responsabilidade a uma fração de onde você costuma assentar; aqui está a linguagem substituta que restaura seu limite normal, na própria redação do contrato, pronta para mandar de volta. Uma é uma reclamação. A outra é um redline, a edição de fato, o texto riscado e a substituição proposta, rascunhada para cair no documento e voltar para a mesa.

Esse rascunho é onde o playbook compensa duas vezes. A contraproposta não é inventada de um senso de justiça. É puxada da linguagem que você negociou com sucesso antes, o limite exato, a janela de aviso exata, o termo de pagamento exato que o outro lado já aceitou de você no passado. O sistema não está adivinhando o que você quereria. Está propondo o que você já ganhou, numa linguagem que uma contraparte já aceitou, porque aprendeu ambos dos deals em arquivo.

Três cláusulas sinalizadas, três contrapropostas rascunhadas, cada uma uma edição real e não um sentimento sobre uma edição. Essa é a diferença entre uma ferramenta que revisa e uma ferramenta que negocia a primeira passada por você.

Jogada três: nomeie o risco para que um humano possa decidir

A terceira jogada é a que mantém isso honesto, e é a que a maioria das demos de “advogado IA” pula.

Cada sinalização carrega um motivo, em linguagem simples, sobre o que a cláusula te custa se você a assinar como está. Não “isto é fora do padrão”. Mas sim: como está, este limite significa que um incidente de pior caso te expõe bem além do seu teto usual, aqui está o cenário em que isso morde. A renovação automática sem janela de aviso: como está, isto renova silenciosamente, então daqui a um ano você está preso por mais um termo a menos que alguém lembre de cancelar dentro de uma janela que não está especificada. O termo de pagamento encurtado: isto puxa caixa para fora mais rápido que sua norma; aqui está o efeito no capital de giro se você disser sim.

O motivo é o produto inteiro, pela mesma razão que era o produto inteiro em qualquer briefing que vale a pena ler. Uma sinalização sem motivo é um chute que você é pedido a confiar. Uma sinalização com um risco nomeado é inteligência sobre a qual você pode agir, e discordar, e sobrescrever, porque você sabe algo que o contrato não sabe. Talvez este fornecedor seja estratégico e o termo de pagamento curto valha a pena. Talvez o limite baixo esteja ok porque o engajamento é minúsculo. O sistema não sabe disso. Você sabe. Então o trabalho do sistema termina precisamente onde o juízo começa: ele traz à tona o desvio, rascunha o conserto, nomeia o custo, e então para.

Esse stop não é uma limitação. É o design.

Dois jeitos de o contrato ser tratado. Na pista ingênua um humano lê todas as vinte e duas páginas sozinho, perde a cláusula fora-do-mercado enterrada, e assina. Na pista da Apollo o sistema avalia cada cláusula contra o playbook, rascunha contrapropostas com riscos nomeados, e um humano revisa três sinalizações em vez de vinte e duas páginas e detém a decisão final.

Onde a linha fica: ele faz o redline, você assina

Vale ser exato sobre o limite, porque este é o limite que torna a coisa inteira usável.

A Apollo é construído para que o sistema faça a comparação e o rascunho, as partes que são tediosas, propensas a erro, e dependentes de uma memória que nenhum humano confiavelmente tem às 17h de uma sexta. Ele lê a cláusula, a avalia contra seu histórico, rascunha a contraproposta, nomeia o risco. O que ele não faz é decidir. Ele não manda o redline de volta sozinho. Ele não assina. O contrato é uma decisão com dinheiro e responsabilidade em cima, e uma decisão dessas roteia para uma pessoa toda vez, do mesmo jeito que uma mudança séria num codebase sério roteia para um revisor antes de fazer merge.

Essa é a mesma forma que todo agent confiável tem, e vale dizer com clareza: o sistema se move primeiro e decide por último. Ele faz a montagem enquanto você não está olhando, e te entrega uma decisão em vez de uma tarefa. A cláusula fora-do-mercado que teria escorregado é agora uma sinalização com um conserto e um motivo anexados. Você lê três coisas em vez de vinte e duas páginas. E a única coisa que sempre foi sua, se este deal, nesses termos, é um que você quer, é a única coisa que o sistema deixa inteiramente com você.

Redlining não é ler um contrato, é avaliar cada cláusula contra os deals que você já acordou, sinalizar o termo fora-do-mercado, rascunhar a contraproposta, e nomear o risco. A leitura nunca foi a parte difícil. A memória era.

A virada: pare de ser a memória de contratos da sua empresa

Aqui está a parte que não é sobre software.

Agora mesmo, na maioria das empresas, alguém é a memória de contratos. É a pessoa que negociou o suficiente destes para sentir quando um termo está fora, que lê a cláusula 9.3 e algo coça, mesmo que não consiga dizer imediatamente por quê. Esse instinto é real, e é valioso, e também é um ponto único de falha vestindo uma pessoa. Ele não escala além dos deals que um humano consegue segurar. Ele sai pela porta quando ela aceita um novo emprego. E falha exatamente quando é mais necessário, às 17h de uma sexta, na vigésima segunda página, quando ela está cansada e o deal é “basicamente padrão”.

Esse instinto merece ser um sistema, não o fardo de uma pessoa. Não porque a pessoa não é boa nisso, ela é a melhor nisso, que é exatamente por que o tempo dela não deveria ser gasto relendo boilerplate para achar a única cláusula que se moveu. O ponto de fazer redline contra um playbook é que o playbook para de morar numa cabeça e passa a morar na empresa. O desvio é pego esteja o especialista na sala ou numa praia. E o especialista ganha a chance de fazer a parte que só ele consegue: não achar a cláusula fora-do-mercado, mas decidir, com a cláusula já achada e a contraproposta já rascunhada, se este é um deal que vale a pena fazer afinal.


É isso que estamos construindo na Apollo, não uma ferramenta que lê seus contratos mais rápido, mas um company brain que lembra de cada deal que você assinou e avalia o próximo contra ele, para que a cláusula fora-do-mercado nunca passe da sexta. Se você já assinou algo que teria pego numa segunda, você já sabe que o problema nunca foi o contrato. Foi que a memória de todos os seus outros contratos não estava na sala.

A Apollo cuida da operação repetitiva da sua empresa pro seu time não precisar.

Entre na lista de espera: acesso antecipado, preço de usuário fundador e um lugar na primeira fila enquanto a gente constrói.

Entrar na lista de espera