O livro de Robert Taylor, Legal Engineering: Building AI-Powered Legal Workflows with Multi-Agent Architectures, é o primeiro guia abrangente sobre uma disciplina que se situa na interseção entre a prática jurídica, a engenharia de software e a conceção de sistemas de IA. Este artigo resume o âmbito completo do livro — os dezasseis capítulos, mais a introdução e a conclusão — com foco no conceito central: a engenharia jurídica.
A engenharia jurídica não é engenharia de prompts. Não é tecnologia jurídica no sentido tradicional. É a prática de conceber, construir e implementar fluxos de trabalho com IA que automatizam o trabalho jurídico usando arquiteturas de pipeline multiagente. Este resumo cobre os padrões fundamentais, os princípios arquiteturais e os dez fluxos de trabalho aplicados que tornam essa definição concreta.
O que é a engenharia jurídica e porque importa
A engenharia jurídica situa-se na interseção de três domínios. A prática jurídica fornece o conhecimento substantivo do que é um trabalho jurídico correto: as regras doutrinais, as obrigações profissionais, as restrições regulatórias e o critério prático que separa a análise competente da negligência profissional. A engenharia de software fornece a disciplina de construir sistemas fiáveis, sustentáveis e prontos para produção: segurança de tipos, tratamento de erros, testes, implementação e monitorização operacional. A conceção de sistemas de IA fornece os padrões arquiteturais que tornam os grandes modelos de linguagem úteis em escala: decomposição de prompts, orquestração multiagente, execução paralela e síntese de resultados.
Um engenheiro de prompts otimiza uma mensagem para um modelo. Um engenheiro jurídico concebe um sistema de vinte ou trinta chamadas de IA coordenadas, cada uma com um papel especializado, orquestradas ao longo de várias rondas sequenciais, produzindo um resultado que cumpre o padrão de diligência exigido para trabalho jurídico.
A característica que define a engenharia jurídica é o tratamento da lógica jurídica e da lógica computacional como a mesma estrutura formal expressa em sintaxes diferentes. Uma data num contrato e um objeto Date em TypeScript são a mesma coisa. Uma cláusula condicional e uma instrução if são a mesma coisa. Uma lista de obrigações e um array de strings são a mesma coisa. Isto não é uma analogia. É um isomorfismo estrutural, e é o que torna toda a disciplina possível.
O livro serve quatro públicos: advogados que querem construir sistemas de IA (não apenas interrogar chatbots), engenheiros de software a entrar na vertical jurídica, profissionais de operações jurídicas a avaliar ferramentas de IA, e estudantes que seguem carreiras na interseção entre direito e tecnologia.
Parte I: Fundamentos
Capítulo 1: O essencial em tecnologia
O primeiro capítulo estabelece a pilha tecnológica que sustenta todos os pipelines de engenharia jurídica: TypeScript para desenvolvimento com segurança de tipos, a API Claude da Anthropic para inferência de IA, OOXML para manipulação de documentos, Express para infraestrutura de servidor, e React para interfaces de utilizador. Cada tecnologia desempenha um papel específico na arquitetura.
O TypeScript é a linguagem de programação do engenheiro jurídico porque a segurança de tipos apanha erros antes de chegarem aos clientes. Um sistema de análise de contratos que rebenta porque alguém passou uma string onde se esperava um número não é um pequeno incómodo — é um risco de negligência profissional. A API Claude fornece a camada de inferência, com suporte para respostas em streaming e janelas de contexto alargadas, necessárias para analisar contratos de cinquenta páginas. O OOXML é o formato de documento que permite aos sistemas de engenharia jurídica produzir Track Changes reais no Microsoft Word — não comentários, não realces, mas alterações controladas indistinguíveis do trabalho de um advogado humano.
Capítulo 2: TIRO — o padrão universal de decomposição
O TIRO (Trigger, Input, Requirements, Output — Gatilho, Entrada, Requisitos, Resultado) é o padrão fundamental da engenharia jurídica. Toda cláusula legal, toda disposição regulatória, todo fluxo de conformidade e toda etapa de um pipeline de IA segue esta estrutura de quatro fases. Um estudante de direito do primeiro ano lê uma cláusula de indemnização e vê prosa impenetrável. Um engenheiro jurídico lê a mesma cláusula e vê uma função: tem um gatilho (violação de uma declaração), entradas (a parte que viola, o valor dos danos, o teto), requisitos que processam essas entradas, e um resultado (a parte indemnizada recebe o pagamento).
A fase de Requisitos decompõe-se em quatro subcomponentes: Arbitragem (resolver conflitos entre prioridades concorrentes), Definições (estabelecer o significado dos termos), Validações (impor restrições sobre os dados) e Transformações (converter entradas em resultados). Juntos, estes quatro subcomponentes captam todas as operações possíveis que uma cláusula jurídica ou uma etapa de um pipeline de IA possa realizar.
A cláusula de indemnização e a função TypeScript que a modela contêm os mesmos gatilhos, aceitam as mesmas entradas, impõem as mesmas restrições, realizam as mesmas transformações e produzem os mesmos resultados. A única diferença é a notação.
O TIRO não é um enquadramento imposto às operações jurídicas. É uma descrição formal da estrutura que as operações jurídicas já têm e sempre tiveram. Toda cláusula contratual é uma função. Não metaforicamente. Não de forma vaga. Estrutural, formal e completamente. Este isomorfismo é o que torna a engenharia jurídica possível: os documentos jurídicos são dados estruturados escritos em linguagem natural, e os sistemas de IA conseguem interpretar essa estrutura porque a lógica subjacente é idêntica à lógica que os sistemas de software já processam.
Capítulo 3: Pipelines de múltiplas passagens
Este capítulo aborda a escolha arquitetural fundamental na IA jurídica: passagem única versus múltiplas passagens. Imagine entregar a um advogado júnior um contrato SaaS de cinquenta páginas e dizer: leia isto, identifique todos os riscos, sugira correções, redija linguagem de substituição, formate a sua análise como um relatório estruturado e redija um e-mail de negociação. Tem uma passagem. Sem notas, sem esboço, sem revisão. Nenhum advogado competente trabalharia assim. E, no entanto, é exatamente assim que a maioria das organizações usa a IA.
Os resultados são mensuráveis. Numa experiência controlada, o mesmo modelo Claude, a analisar o mesmo contrato de M&A com 42.274 palavras, produziu 35 alterações controladas sem qualquer citação jurídica numa única passagem. O mesmo modelo, envolto num pipeline de 26 agentes e 6 rondas, produziu 138 alterações controladas com 18 citações jurídicas. Uma melhoria de 3,9x sem qualquer alteração na capacidade do modelo. A arquitetura foi a única variável.
A passagem única falha de quatro formas previsíveis: diluição da atenção (cláusulas críticas competem com texto-padrão pelo peso de processamento), ausência de especialização (um único prompt tenta ser analista de risco, redator jurídico, estratega de negociação e formatador de documentos simultaneamente), ausência de autocorreção (uma definição mal interpretada propaga-se silenciosamente por toda a análise) e ausência de auditabilidade (não é possível identificar qual etapa produziu um resultado defeituoso).
O livro apresenta dois padrões fundamentais para resolver isto. O Diplomat é uma arquitetura emparelhada de gerador-executor de prompts: um agente gera o prompt, outro executa-o. Esta separação cria interfaces tipadas e auditáveis entre etapas. O Backautocrat é o orquestrador que encadeia múltiplas etapas Diplomat num pipeline completo, gerindo transições de estado, recuperação de erros e recolha de métricas ao longo de todas as rondas.
Capítulo 4: Paralelização
Um contrato SaaS típico tem pelo menos dezasseis áreas distintas de preocupação: propriedade intelectual, condições de pagamento, garantias de SLA, tetos de responsabilidade, indemnização, direitos de rescisão, proteção de dados, entre outras. Se se correrem dezasseis analisadores sequencialmente, a trinta segundos cada, o utilizador espera oito minutos. Corridos em paralelo, o utilizador espera trinta segundos. Mesmo custo computacional. Mesmo consumo de tokens. A única coisa que mudou foi a arquitetura.
O livro ensina a arquitetura fan-out/fan-in: despachar dezenas de agentes de IA especializados simultaneamente, recolher os seus resultados à medida que terminam, e agregar tudo numa única análise coerente. Os sistemas em produção implementam mais de 158 analisadores paralelos contra um único contrato, usando Promise.allSettled() para uma execução tolerante a falhas. Uma perceção crítica: fragmentos paralelos sem síntese são piores do que uma única passagem coerente. Um agente sintetizador obrigatório tem de resolver contradições e produzir um resultado unificado.
Capítulo 5: Integração
Um pipeline de IA que corre num terminal e imprime resultados na consola não é um produto. A integração é a disciplina de engenharia que liga um pipeline de IA a todos os sistemas que precisa de tocar: um painel React para carregamentos, um backend Express para orquestração, uma base de dados para persistência, armazenamento na nuvem para documentos, e um sistema de entrega que produz documentos do Microsoft Word com Track Changes visíveis.
O capítulo cobre a cirurgia de Track Changes em OOXML (o formato que torna as alterações controladas geradas por IA indistinguíveis do trabalho de um advogado humano), Server-Sent Events para transmissão de progresso em tempo real, design de API para endpoints de pipeline, e padrões de implementação. A perceção-chave é que a precisão do OOXML importa tanto quanto a precisão analítica: uma análise jurídica brilhante entregue no formato errado é inútil na prática.
Capítulo 6: Privilégio e segurança
Este capítulo é onde a engenharia de software cruza a linha para a engenharia jurídica. Os conceitos aqui não têm equivalente numa base de código SaaS típica. Vêm de séculos de jurisprudência, regras de responsabilidade profissional e enquadramentos regulatórios. E não são opcionais.
Quando um escritório de advogados envia um acordo de aquisição de M&A privilegiado através de uma ferramenta SaaS de terceiros que processa os dados nos seus próprios servidores, com as suas próprias chaves de API, sob os seus próprios termos de serviço, o privilégio foi renunciado? A resposta depende da arquitetura. O livro cita o caso Mata v. Avianca (S.D.N.Y. 2023), em que advogados foram sancionados por petições geradas por IA com citações fabricadas. Mas as questões de privilégio são bem mais consequentes.
Um pipeline de redação de contratos que viola o privilégio advogado-cliente é pior do que inútil. É um risco de negligência profissional à espera de surgir em fase de descoberta processual. As implicações não são teóricas.
A engenharia jurídica exige classificação de dados (categorizar cada informação por estatuto de privilégio e sensibilidade), propriedade da infraestrutura (o escritório tem de controlar onde os dados são processados), controlos de acesso (isolamento baseado em funções e em processos) e trilhos de auditoria que satisfaçam tanto os requisitos regulatórios como eventuais retenções de litígio.
Parte II: Fluxos de trabalho aplicados
A Parte II aplica os padrões fundamentais a dez fluxos de trabalho jurídicos distintos. Cada capítulo segue a mesma estrutura: definir o fluxo de trabalho, decompô-lo usando o TIRO, conceber a arquitetura do pipeline, implementá-lo e avaliar os resultados face aos padrões profissionais. O que emerge é a demonstração de que uma única arquitetura se generaliza por toda a prática do direito.
Capítulo 7: Redação de contratos
A redação de contratos é o ponto de partida mais natural para a engenharia jurídica aplicada, porque as entradas e os resultados são concretos. A entrada é um manual de instruções do cliente: uma expressão estruturada do que o cliente quer, do que aceita e do que não tolera. O resultado é um acordo completo e exequível que se lê como se um sócio sénior o tivesse escrito.
Entre esses dois extremos situa-se um pipeline de seis etapas: classificar o negócio, gerar uma folha de termos, redigir cláusulas individuais (usando redatores especialistas paralelos para cada secção), resolver referências cruzadas, montar o documento e rever o resultado final. Cada etapa é um Diplomat. Cada transição é uma interface tipada. O Backautocrat orquestra todo o fluxo e capta métricas em cada passo.
Capítulo 8: Revisão de alterações contratuais — a aplicação de IA de maior valor
A revisão de alterações contratuais destaca-se como a aplicação de maior valor da inteligência artificial na prática jurídica. A economia é evidente: uma revisão de alterações ao nível de sócio de um contrato SaaS de cinquenta páginas demora entre oito a doze horas de tempo dedicado de um advogado. A taxas de escritórios de topo entre $800 e $1.500 por hora, isso representa entre $6.400 e $18.000 por contrato. Um pipeline de revisão de alterações com IA produz o mesmo resultado em trinta minutos.
Não uma aproximação de alterações. Não comentários realçados. Alterações controladas reais, incorporadas na estrutura XML do contrato, indistinguíveis das alterações que um advogado humano faria no Microsoft Word. O pipeline de revisão de alterações usa análise adversarial: a IA lê o contrato como se representasse o oponente da contraparte, identificando todas as cláusulas que favorecem o outro lado, quantificando o risco e gerando linguagem de substituição com autoridade jurídica de suporte.
Capítulo 9: Análise de contratos
Um diretor jurídico com 500 contratos ativos enfrenta uma pergunta do conselho de administração: qual é a nossa exposição total de indemnização em toda a carteira de fornecedores? Na maioria dos departamentos jurídicos, essa pergunta desencadeia semanas de trabalho. Os associados abrem os contratos um a um, digitam números numa folha de cálculo e, eventualmente, produzem um intervalo tão amplo que se torna praticamente inútil.
A mudança fundamental: um contrato não é um documento para ler. É uma base de dados para consultar. Todo o acordo SaaS contém uma percentagem de disponibilidade de SLA, um teto de responsabilidade, um prazo de vigência, um sinalizador de renovação automática, uma jurisdição de lei aplicável e condições de pagamento. Não são prosa. São campos. Uma vez tratados como campos, é possível fazer com 500 contratos o que uma folha de cálculo faz com 500 linhas: filtrar, ordenar, agregar, alertar. O pipeline de análise usa extração orientada por esquema, com agregação de carteira, para responder a perguntas de nível de conselho de administração em minutos.
Experimente HAQQ AI grátis
Experimente a redação e pesquisa jurídica com IA
Capítulo 10: Comunicações reguladas
A 15 de março de 2024, uma corretora de média dimensão pagou $4,2 milhões para resolver acusações da FINRA sobre publicações em redes sociais que a sua equipa de conformidade tinha aprovado. Uma palavra — 'garantido' — num único tweet desencadeou uma ação de fiscalização que consumiu dezoito meses de honorários jurídicos. O problema não foi descuido. O problema é que nenhum ser humano consegue manter simultaneamente na memória de trabalho a Regra 156 da SEC, a Regra 2210 da FINRA, os requisitos estaduais de blue-sky e as políticas internas de publicidade do escritório, enquanto lê uma publicação de 280 caracteres.
As comunicações reguladas acarretam risco direto de fiscalização. Uma alegação enganosa numa carta a investidores é uma potencial violação de valores mobiliários. Um e-mail de marketing farmacêutico que omite avisos de segurança obrigatórios é uma infração regulatória da FDA. O pipeline de engenharia jurídica aplica camadas de conformidade multiframework: cada comunicação é simultaneamente analisada face a múltiplos enquadramentos regulatórios por agentes especialistas paralelos, cada um treinado num corpo específico de regulamentos.
Capítulo 11: Risco de terceiros
A violação da SolarWinds em 2020 expôs 18.000 clientes através de uma atualização de software comprometida. A Target perdeu 40 milhões de números de cartões de crédito através de um fornecedor de HVAC comprometido. O perímetro de segurança de uma organização é tão forte quanto o seu fornecedor mais fraco. A gestão de risco de terceiros é um fluxo de trabalho de engenharia jurídica que avalia fornecedores usando avaliação de risco por níveis, modelação de maturidade e análise automatizada de questionários.
O pipeline classifica fornecedores por nível de risco, implementa analisadores especializados para cada dimensão de risco (postura de cibersegurança, práticas de tratamento de dados, conformidade regulatória, estabilidade financeira), sintetiza os resultados numa pontuação de risco e gera recomendações acionáveis. Organizações com centenas de relações com fornecedores conseguem manter monitorização contínua de risco em vez de revisões pontuais anuais.
Capítulo 12: Triagem de documentos
Um departamento jurídico empresarial recebe quarenta documentos num único dia. Uma resolução do conselho, contratos de fornecedores a renovar, uma carta de cessação e desistência às 16h47, aditamentos, contratos de trabalho, uma carta de exigência a ameaçar litígio com um período de correção de dez dias. A maioria das organizações lida com isto da mesma forma: um paralegal rotula cada documento e coloca-o numa pasta. Se a carta de exigência ficar parada três dias porque o advogado responsável está em depoimentos, o período de correção expira em silêncio.
A triagem de documentos usa classificação especializada com encaminhamento por urgência. O pipeline identifica o tipo de documento, extrai prazos críticos, avalia a urgência, determina qual advogado ou equipa deve tratar cada documento, e encaminha em conformidade, com alertas automatizados. A diferença entre rotular um documento como 'Carta de Exigência' e extrair o seu prazo de correção de dez dias é a diferença entre um sistema de arquivo e um sistema de engenharia jurídica.
Capítulo 13: Rastreamento de obrigações
Uma empresa de tecnologia de média dimensão assina o seu duocentésimo contrato de fornecedor e enterra o PDF assinado numa unidade partilhada. Algures na página catorze está uma cláusula que exige noventa dias de aviso prévio por escrito antes de qualquer renovação automática. Algures na página vinte e um está um requisito de manter cobertura mínima de seguro certificada anualmente. Ninguém lê essas páginas depois de assinar. Nove meses depois, o contrato renova-se automaticamente a uma taxa vinte por cento acima do mercado. Quatro meses mais tarde, uma auditoria revela que a certificação de seguro caducou, desencadeando uma cláusula de incumprimento material.
O rastreamento de obrigações usa pipelines de extração com calendarização e alertas. O sistema lê todos os contratos, identifica todas as obrigações (prazos de pagamento, marcos de entrega, janelas de aviso, certificações de conformidade, gatilhos de renovação, direitos de auditoria, requisitos de manutenção de seguro), cria entradas de calendário estruturadas e envia alertas antes de os prazos se aproximarem. Duas obrigações enterradas em duzentas páginas de duzentos contratos deixam de custar seis dígitos em sobrecustos.
Capítulo 14: Due diligence em M&A
Uma aquisição de mercado intermédio fecha depois de três associados registarem 1.800 horas faturáveis a rever 2.400 documentos. A fatura totaliza $1,2 milhões. Seis meses depois, o comprador descobre que o produto principal da empresa-alvo assenta numa licença de propriedade intelectual que se extingue automaticamente com a mudança de controlo. A licença era o documento 1.847 de 2.400, revisto no dia 31 de um período de due diligence de seis semanas, por um associado cuja capacidade cognitiva para detetar armadilhas subtis de referências cruzadas era, a essa altura, praticamente nula.
A due diligence de M&A usa análise de risco em seis dimensões, com mapeamento de mudança de controlo. O pipeline processa todos os documentos na sala de dados contra uma checklist de due diligence, com agentes especializados a analisar riscos de propriedade intelectual, obrigações laborais, conformidade regulatória, gatilhos contratuais de mudança de controlo, exposição a litígios e passivos financeiros. O sistema não substitui o associado — garante que o documento 1.847 recebe o mesmo rigor analítico que o documento 1.
Capítulo 15: Apoio ao contencioso
O contencioso moderno gera volumes impressionantes de informação armazenada eletronicamente. Uma única investigação antitrust pode produzir dez milhões de documentos. A revisão tradicional custa entre um e dois dólares por documento — entre dez e vinte milhões de dólares antes de um único depoimento ser tomado. A primeira geração de tecnologia de revisão assistida (TAR) reduziu custos, mas exigia rondas de treino humano dispendiosas, tinha dificuldades com classificação multirrótulo e tratava o privilégio como uma reflexão tardia.
A engenharia jurídica é a segunda vaga. Arquiteturas multiagente classificam, codificam e filtram documentos com precisão especializada, a uma fração do custo, e com métricas de defensabilidade que os tribunais já aceitaram. O pipeline de apoio ao contencioso trata a revisão de e-discovery, a filtragem de privilégio (uma preocupação crítica que exige soluções arquiteturais, não apenas engenharia de prompts) e a codificação de questões, com trilhos de auditoria completos.
Capítulo 16: Investigação jurídica
A investigação jurídica é o alicerce invisível da prática do direito. Uma questão complexa de contencioso pode consumir entre 20 e 40 horas de tempo de um associado, a $400-800 por hora. A profissão jurídica gasta milhares de milhões de horas por ano em trabalho que é fundamentalmente sobre ler, sintetizar e aplicar informação — exatamente o tipo de trabalho cognitivo em que as arquiteturas de IA multiagente se destacam.
O pipeline de investigação jurídica usa investigação paralela com verificação obrigatória de citações. Múltiplos agentes especialistas investigam diferentes aspetos de uma questão jurídica em simultâneo (autoridade legal, jurisprudência, orientação regulatória, fontes secundárias), e depois um agente de síntese reúne os resultados num memorando estruturado com citações verificadas. A restrição crítica: toda citação tem de ser verificada contra bases de dados jurídicas reais. Citações alucinadas não são uma falha menor — são a base de sanções, como demonstrou o caso Mata v. Avianca.
A conclusão: a arquitetura como multiplicador permanente
A tese do livro não é que a IA vai mudar a prática jurídica. Isso é óbvio. A tese é que a arquitetura é o que separa a IA que produz trabalho ao nível de sócio da IA que produz resumos caros. O mesmo modelo de fronteira, dado o mesmo contrato, produz 35 alterações controladas sem qualquer citação quando usado como um único prompt, e 138 alterações controladas com 18 citações jurídicas quando envolto num pipeline multiagente. O modelo não ficou mais inteligente. A arquitetura melhorou.
Dez fluxos de trabalho. Uma arquitetura. Isso não é coincidência. É uma disciplina.
Três desenvolvimentos vão moldar a próxima fase. Primeiro, a capacidade dos modelos vai continuar a melhorar, mas a vantagem arquitetural vai persistir. Modelos melhores elevam o piso de qualidade dos sistemas de passagem única, mas também elevam o teto dos pipelines multiagente na mesma proporção. A arquitetura é um multiplicador permanente, não uma solução temporária.
Segundo, a integração com bases de dados jurídicas vai fechar o fosso de verificação. Quando os pipelines conseguirem consultar a Westlaw ou a Lexis programaticamente, a verificação de citações torna-se determinística em vez de probabilística. As citações alucinadas tornar-se-ão um problema resolvido.
Terceiro, o mercado vai bifurcar-se. Os escritórios e departamentos jurídicos que adotarem fluxos de trabalho de IA engenheirados vão operar com estruturas de custo fundamentalmente diferentes. Uma revisão de contrato que custa $15.000 e demora duas semanas sem IA vai custar $2.000 e demorar dois dias com um pipeline devidamente engenheirado. Isso não é uma melhoria marginal. É uma vantagem estrutural que se acumula em cada processo, cada mês, cada ano.
Principais conclusões
- A engenharia jurídica é a prática de conceber, construir e implementar fluxos de trabalho com IA que automatizam o trabalho jurídico usando arquiteturas de pipeline multiagente. Não é engenharia de prompts nem tecnologia jurídica pronta a usar.
- O padrão TIRO (Gatilho, Entrada, Requisitos, Resultado) é o modelo universal de decomposição. Toda cláusula jurídica e toda etapa de um pipeline de IA segue esta estrutura.
- Pipelines de múltiplas passagens com agentes especialistas produzem resultados mensuravelmente melhores do que prompts de passagem única: 3,9x mais achados, 18 citações jurídicas contra zero, a partir do mesmo modelo sobre o mesmo contrato.
- A paralelização via padrões fan-out/fan-in permite análise em tempo real, ao implementar dezenas de agentes especialistas simultaneamente, mas exige um sintetizador obrigatório para produzir um resultado coerente.
- O privilégio advogado-cliente impõe restrições arquiteturais que nenhuma engenharia de prompts, por mais engenhosa, consegue satisfazer. O escritório tem de ser dono da infraestrutura.
- A cirurgia de Track Changes em OOXML é o que torna as alterações controladas geradas por IA indistinguíveis do trabalho de um advogado humano. A precisão de formato importa tanto quanto a precisão analítica.
- A mesma arquitetura fundamental generaliza-se por dez fluxos de trabalho jurídicos distintos: redação de contratos, revisão de alterações, análise de contratos, comunicações reguladas, risco de terceiros, triagem de documentos, rastreamento de obrigações, due diligence em M&A, apoio ao contencioso e investigação jurídica.
- A arquitetura é um multiplicador permanente. Modelos melhores vão elevar o piso, mas pipelines devidamente engenheirados vão sempre superar o uso de passagem única do mesmo modelo.
- O mercado vai bifurcar-se entre escritórios que adotam fluxos de trabalho de IA engenheirados e os que não o fazem. As vantagens de custo e velocidade são estruturais, não marginais.
- O critério do advogado continua a ser o núcleo irredutível. A engenharia jurídica trata de tudo exceto o critério, para que a experiência do advogado possa ser aplicada a um trabalho já minucioso, bem investigado, devidamente formatado e internamente consistente.
