Geração de Regras de Triagem com IA

O DATTA propõe as regras de triagem de um código inteiro para você — ancoradas no texto real de cada dispositivo, enriquecidas com a jurisprudência vigente e sem recriar o que já existe. Escrever essas regras à mão para um código com mais de mil artigos, e ainda mantê-las alinhadas ao entendimento das cortes, é projeto de meses. Com Gerar Regras com IA, você descreve o que quer validar (ou pede a cobertura do código inteiro) e acompanha as regras chegando em tempo real.

Veja também: como o código processual entra na base e a triagem em lote, que executa essas regras.

Onde fica e os três modos

O painel está em Processar›Regras. Ao clicar em Gerar Regras com IA, você escolhe o contexto legal — o painel exibe sempre o rótulo configurado (ex.: "Código de Processo Civil"), nunca a chave interna — e preenche dois campos: Quantidade de regras e Foco específico (texto livre). A combinação deles, mais a caixa "Gerar todas as regras possíveis para o código", seleciona um de três modos:

Em qualquer modo, quem propõe as regras é o modelo de linguagem configurado para o contexto, e as regras aceitas são gravadas na base de grafo do próprio contexto. Gerar regras exige a permissão RULES_EDIT.

Como a geração se comporta enquanto roda

Em qualquer modo a resposta é imediata: a geração roda em segundo plano e o diálogo vira uma tela de progresso em tempo real — fase atual, barra de progresso, contadores de sugeridas/novas/ignoradas e o feed das regras aceitas.

• Pode fechar o diálogo. A geração continua e o acompanhamento é retomado quando você reabre a página.
• Pode cancelar a qualquer momento.
• Uma geração por contexto de cada vez. Pedir outra durante uma geração ativa apenas acopla você ao progresso da que já está rodando.

Integrações podem disparar e acompanhar a geração pelos mesmos recursos que a tela usa — veja a referência de API.

Modo temático — quantidade sob controle

O campo Quantidade de regras aceita de 1 a 50 (padrão 5) e define quantas regras novas criar. O campo Foco específico entra na instrução enviada ao modelo como direcionamento temático.

• Só cria regras genuinamente novas. Este modo usa a mesma deduplicação semântica do modo abrangente contra todas as regras já existentes do contexto. Como "todas as regras possíveis" não é um conjunto fechado (sempre dá para fatiar um artigo em regras mais granulares), pedir N regras depois de uma geração completa não produz N quase-duplicatas: cada sugestão é comparada e descartada se já existe regra parecida.
• Completa a cota com rodadas. Se, depois da deduplicação, sobrarem menos de N regras novas, a plataforma faz rodadas adicionais — excluindo o que já existe — para tentar atingir a quantidade pedida. Ela para antes se o código saturar (duas rodadas seguidas sem nenhuma regra nova) ou ao atingir o teto de rodadas, e então informa quantas criou e quantas ignorou por similaridade. Se realmente não há mais regra distinta a criar, ela cria zero e avisa — nunca inventa regra para preencher o número.

Modo direcionado — ancorado no artigo real

Quando o Foco específico referencia um dispositivo, a geração deixa de ser genérica e passa a ser fundamentada no texto real do artigo. Exemplo:

"Crie uma regra para validar se o código 1030 do CPC está sendo aplicado de forma correta."

O que acontece:

1. Reconhecimento da citação — as formas usuais são detectadas: art 1030, artigo 1030, art. 1030-A, código 1030, 1030 do CPC/CPP/CDC/PAF.
2. Busca do dispositivo — o texto real do artigo é lido da base de grafo do contexto.
3. Jurisprudência — as decisões vinculadas ao artigo são carregadas.
4. Geração ancorada — a instrução enviada ao modelo inclui o texto real do dispositivo e a jurisprudência; a regra resultante cita o dispositivo (Art. N) na própria redação.
5. Deduplicação por título exato contra as regras existentes do contexto.

Se nenhum dos artigos citados existir na base, a geração recua para o modo temático genérico — você nunca fica sem regra. As regras criadas recebem a numeração IA-<contexto>-NNN.

Modo abrangente — o código inteiro

Marcando "Gerar todas as regras possíveis para o código", a geração cobre o código completo, ancorada nos artigos reais:

1. A plataforma resolve a base de destino do contexto e carrega os artigos (número + texto), até o teto de artigos por execução (o corte é feito pela ordem dos artigos e fica registrado em log).
2. Os artigos são processados em blocos (padrão 10 por bloco). Cada bloco vira uma instrução com o texto real dos dispositivos e a jurisprudência de cada um.
3. Os blocos correm em paralelo (padrão 4 simultâneos), com controle de vazão para não sobrecarregar o modelo.
4. A deduplicação semântica impede recriar regra parecida — com as já existentes ou com outra gerada na mesma execução.
5. Um teto de regras criadas por execução funciona como salvaguarda contra disparada acidental (não é limite de produto).

Para um código grande (o CPC tem cerca de 1.073 artigos) a operação leva alguns minutos — por isso roda em segundo plano com a tela de progresso: blocos concluídos e regras sugeridas/novas/ignoradas em tempo real. Ao final, a mensagem informa quantas regras foram criadas e quantas foram ignoradas por já existir regra parecida.

Jurisprudência vigente nas regras

Os processos são validados contra a jurisprudência vigente — por isso os modos direcionado e abrangente a consideram sempre que ela existir na base:

• Para cada artigo, a jurisprudência vinculada a ele é carregada com ementa resumida + tribunal, até 3 decisões por dispositivo (economia de contexto enviado ao modelo).
• Quando o artigo está marcado com entendimento divergente, a instrução sinaliza que a regra deve validar a conformidade segundo a interpretação consolidada das cortes, e não apenas o texto literal do dispositivo.
• A instrução inclui explicitamente que os processos serão validados em relação à jurisprudência vigente.

Pré-requisito de dados. O enriquecimento só ocorre se o contexto tiver jurisprudência ingerida — a ingestão (DataJud, STJ Dados Abertos, STF, TST) liga os acórdãos ao artigo; veja o guia de fontes de jurisprudência e a arquitetura das fontes. Sem jurisprudência na base, a geração funciona normalmente, apenas sem o enriquecimento.

Sem duplicatas — deduplicação semântica

Para não recriar regras que já existem com outra redação, cada sugestão é comparada com a base por similaridade de significado, não só de texto:

• A plataforma gera o vetor de cada regra (título + texto) com o modelo de embeddings ativo — hoje o Qwen3-Embedding-0.6B, de 1024 dimensões — em chamadas autenticadas de serviço.
• As regras existentes do contexto são vetorizadas antes; cada candidata é comparada por cosseno contra a base e contra as já aceitas na mesma execução.
• Similaridade igual ou acima de 0,85 (padrão ajustável) significa "já existe parecida" ⇒ a regra não é recriada.
• Os vetores são normalizados (L2) antes da comparação, o que reduz o cosseno a um produto escalar.
• Degradação graciosa: se o serviço de vetores estiver indisponível, a candidata cai em uma comparação lexical (interseção/continência dos termos normalizados de título e texto) — a proteção contra duplicatas nunca fica desligada.

O nome do contexto vem da configuração

O painel de Regras de Triagem e a Triagem em Lote exibem sempre o rótulo configurado do contexto, lido das configurações da plataforma (a lista de contextos devolve as chaves e os rótulos correspondentes). A chave permanece como identificador interno — usada no filtro, na geração e no envio ao servidor —, mas quem lê a tela vê o nome legível.

A barra de contextos mostra o que tem regra

A fileira de filtros no topo do painel de Regras de Triagem é montada a partir de duas fontes, consultadas ao mesmo tempo:

• os contextos que têm regra, derivados das próprias regras cadastradas, com a contagem de cada um;
• os contextos cadastrados na plataforma, que trazem o rótulo de exibição e fazem um contexto recém-criado aparecer com (0), para que ele possa receber a primeira regra.

Cada opção mostra a contagem entre parênteses — Convenções FEBRABAN (15) —, e Todos continua sem contagem. Apontar o cursor para a opção detalha quantas regras estão ativas e quantas inativas.

Antes, a lista vinha apenas do cadastro de contextos cruzado com a lista de contextos visíveis das configurações. Um contexto com regras que não estivesse nessa lista — ou cuja chave não fosse um contexto cadastrado — sumia do filtro sem aviso, e as regras dele sumiam junto. Agora vale a regra oposta: contexto que tem regra sempre aparece. Quando algum deles não consta entre os contextos cadastrados que a tela recebeu, ela diz quantos são e quais, logo abaixo da fileira, e aponta onde verificar — o contexto pode não estar cadastrado, ou estar fora da lista de visíveis. A tela mostra o fato; ela não adivinha a causa.

Filtrar e criar são coisas diferentes: o filtro lista tudo o que tem regra, mas escolher o contexto de uma regra nova continua limitado aos contextos cadastrados. Ao editar uma regra existente, os contextos que ela já tem aparecem marcados mesmo que estejam fora desse cadastro — para que você os veja e possa retirá-los.

A contagem acompanha as mudanças: criar, editar, ativar/desativar ou apagar regras atualiza a barra na hora, sem recarregar a página. Criar a primeira regra de um contexto novo o faz aparecer imediatamente.

Quando alguma das duas fontes não responde, a tela continua útil e explica o que faltou: sem a lista de contextos com regra, ela volta à lista de cadastrados e avisa que a contagem está indisponível; sem a lista de cadastrados, mostra os contextos que têm regra pela própria chave. Só quando nenhuma das duas responde aparece a mensagem de erro com o botão Tentar novamente.

Gerar e apagar exigem um contexto escolhido

Com o filtro em Todos não há contexto alvo, então Gerar Regras com IA e a manutenção Apagar TODAS as regras existentes pedem que você selecione um contexto específico na barra de filtros. Antes, as duas ações caíam silenciosamente no primeiro contexto da lista — inclusive a destrutiva, que apagava as regras de um contexto que ninguém tinha escolhido.

Depois de criar ou editar regras — triagem incremental

Criou ou alterou uma regra? Não precisa reprocessar o acervo inteiro. No painel Triagem Processual em Lote há, além de "Triar apenas processos novos" e "Reprocessar todos", a opção Apenas regras novas/atualizadas:

• A plataforma identifica as regras cuja data de criação/atualização é posterior à última triagem de cada processo e reavalia somente essas regras, fundindo o resultado com o laudo existente (as demais regras do processo não são reavaliadas).
• Processos cuja última triagem já cobre todas as regras vigentes são marcados como "já atualizados" (com contador próprio no painel) e não são reprocessados.
• É mais rápido e mais barato que "reprocessar todos" e mantém todos os processos em dia com a regra que mudou. Opera apenas sobre processos já triados — processos novos continuam no modo "triar apenas processos novos".

Detalhe técnico: triagem incremental.

Manutenção — apagar todas as regras (somente admin)

O diálogo de geração não contém ações destrutivas. A exclusão em massa fica num lugar separado: ao lado de + Nova Regra há uma engrenagem de manutenção, visível apenas para administradores, que abre o diálogo Manutenção de Regras com a opção Apagar TODAS as regras existentes — operação destrutiva e irreversível, que apaga todas as regras do contexto e não as regenera.

• Aviso explícito no diálogo antes de confirmar.
• Motivo obrigatório (mínimo 10 caracteres): sem justificativa, o botão fica desabilitado.
• Permissão RULES_REPLACE_ALL, sensível e exclusiva do administrador — RULES_DELETE e as demais permissões de regra não habilitam esta ação. O servidor recusa quem não for admin, independentemente do que a interface mostre.
• Tudo auditado: o ato (quantas regras, quem apagou e por quê) é gravado de forma durável e atômica, na mesma transação da exclusão e em banco de sistema — a trilha nunca se perde, mesmo que a auditoria central esteja fora do ar. Além disso, gera um evento RULES.DELETE_ALL visível em Sistema›Logs → Log do Sistema, na categoria AUDITORIA (filtrável), e enviado à trilha de auditoria da plataforma.

Exemplo prático — cobrir o CPC e depois refinar

1. Em Processar›Regras, selecione o contexto "Código de Processo Civil" e clique em Gerar Regras com IA.
2. Marque "Gerar todas as regras possíveis para o código" e confirme. A tela de progresso mostra os blocos avançando; feche o diálogo e volte mais tarde — a geração continua.
3. Ao final, a mensagem resume o resultado: "128 regras criadas, 12 ignoradas por já existir regra parecida."
4. Uma semana depois, para reforçar um ponto específico, gere de novo com Foco específico = "prazos do agravo interno, art. 1021" e Quantidade de regras = 3. Só entram regras que ainda não existem.
5. Rode a triagem em lote no modo Apenas regras novas/atualizadas para aplicar as regras novas sem reprocessar o acervo.

Parâmetros de operação

Todos ajustáveis por variável de ambiente, sem novo build (prefixo datta.rules.*):

A base de destino de cada contexto é resolvida dinamicamente pela configuração da plataforma, com fallback — contextos criados pelo usuário resolvem corretamente, sem nome de base fixado no código. Toda leitura respeita o cache de configuração.

Por que as regras saem confiáveis

• A regra é ancorada no texto real do dispositivo, não no que o modelo "lembra".
• Nenhum nome de contexto é fixado no código — rótulo e base de destino vêm da configuração.
• Nenhuma regra duplicada, em todos os modos (inclusive o temático), graças à deduplicação semântica com fallback lexical.
• A IA não fabrica regras para preencher a quantidade pedida: se o código já tem regras parecidas para tudo, ela cria menos (ou zero) e avisa, em vez de gerar variações redundantes.
• Não há limite artificial de cobertura — o código inteiro pode ser coberto.
• A jurisprudência é considerada, então a validação reflete a interpretação das cortes, não só a letra da lei.