Cada uma dessas ações já era possível antes. Esse é o ponto. O que mudou foi a quantidade de etapas entre querer algo e obtê-lo.
Antes e depois: cinco etapas contra uma única frase.
1. Transforme uma nova lista de preços em uma nova versão
Seu fornecedor envia uma lista de preços atualizada. É um arquivo CSV. Sua tabela de produtos ainda contém os valores antigos.
Antes: Abra o arquivo. Abra a regra. Identifique quais linhas precisam ser atualizadas. Edite-as uma a uma ou exporte para o Excel, faça os ajustes e importe novamente. Certifique-se de que nada mais tenha mudado.
Agora: Faça upload do arquivo e diga ao assistente o que fazer.
Esta é a nova lista de preços do nosso fornecedor. Crie uma nova versão da tabela de consulta Product Prices com esses valores. Mantenha a versão atual intacta e mostre quais linhas foram alteradas.
Crie uma nova versão da regra a partir de uma lista de preços do fornecedor sem alterar a versão em produção.
O assistente lê a tabela atual, associa os novos valores às linhas corretas e cria uma nova versão. Ele não modifica a versão em uso. Você a verifica primeiro.
Procure SKU-4410-GOLD na nova versão. Quanto um cliente Gold paga por 12 unidades?
Peça ao assistente um valor da nova versão da regra e verifique o resultado no chat.
Você vê o resultado no mesmo chat, ao lado dos dados que acabou de adicionar.
2. Crie uma tabela a partir de uma descrição
Antes: Transforme a política em colunas. Defina as entradas e saídas. Crie a tabela. Adicione linhas. Na linha nove, perceba que, afinal, é necessária uma coluna calculada.
Agora:
Crie uma tabela de decisão para aplicar um desconto com base no valor total do pedido e no status do cliente. Clientes Gold recebem 15% de desconto acima de 500; todos os outros recebem 10% acima de 1000.
Transforme uma política em linguagem natural em uma tabela de decisão estruturada.
O Assistente de IA retorna uma tabela pronta para revisão. As entradas e saídas estão definidas, as colunas têm seus tipos configurados e as linhas estão preenchidas.
Isso usa o mesmo mecanismo que possibilita a criação de regras no editor. O MCP apenas muda a forma de acessá-lo.
3. Gere casos de teste que realmente testem alguma coisa
Antes: Percorra as condições das linhas. Escreva as entradas manualmente. O resultado geralmente cobre a lógica que você já entende, não as lacunas que deixou passar.
Agora:
Gere 10 casos de teste para a regra de pontuação de crédito, versão 3. Inclua valores-limite e pelo menos uma entrada que não corresponda a nenhuma linha.
Essa última parte é fundamental. Entradas que não correspondem a nenhuma linha revelam lacunas de cobertura. Esses são os casos que raramente são escritos manualmente.
Aqui está o mais importante. O assistente propõe apenas as entradas. Ele não preenche os resultados esperados. Quando você salva o conjunto, o DecisionRules executa a regra usando exatamente essa versão para definir as saídas. Se a IA escrevesse os dois lados, o teste não teria sentido. Por isso, ela não pode escrever a resposta.
Gere casos de teste relevantes e execute-os como um conjunto reutilizável de testes de regressão.
Os resultados são retornados para cada caso. O conjunto permanece na aba Testes para a próxima vez. É assim que os testes de regressão continuam úteis. E agora você não precisa escrever as entradas manualmente.
4. Pergunte à tabela por quê, não apenas o quê
Um cliente afirma que recebeu uma cobrança incorreta. A tabela de preços tem quarenta linhas, três condições sobrepostas e uma coluna de cálculo adicionada meses atrás. A regra é avaliada corretamente, mas o problema está na lógica.
Antes: Abra a regra. Recrie a entrada no Test Bench. Execute-a. Percorra a avaliação passo a passo.
Agora:
Execute a regra de preços com este pedido e diga qual linha correspondeu e por quê.
Você recebe a linha correspondente, as condições que passaram ou falharam e a forma como o valor final foi calculado. Em seguida, faz a pergunta que realmente ajuda:
Quais outras linhas poderiam ter correspondido a este pedido e por que não foram selecionadas?
Sem o assistente, você gastaria pelo menos vinte minutos investigando o caso: recriando entradas, percorrendo linhas e rastreando a lógica etapa por etapa. Oferecemos o modo de depuração para ajudar, que acelera o processo ao mostrar avaliações no nível das células. Ainda assim, cada verificação é manual. Agora, para obter respostas sobre a lógica, basta fazer a pergunta.
O mesmo recurso possibilita os resumos de regras no editor e é especialmente útil para aquela regra que ninguém se lembra de ter criado.
5. Veja o que uma alteração de versão significa antes de publicar
Antes: Abra a visualização de comparação. Leia as diferenças entre as versões. O que a visualização não consegue informar é o que essas alterações significam para um pedido real ou quem será afetado.
Compare versões de regras para ver quais limites foram alterados e como eles afetam pedidos reais.
Agora:
Compare as versões 3 e 4 da tabela de preços. O que mudou e o que isso significa para um pedido de 400?
As diferenças são apresentadas de forma clara, junto com o impacto. O limite passou de 500 para 400, portanto um pedido de 400 agora recebe um desconto que antes não recebia. Uma linha foi desativada. Um novo nível passou a ficar acima do nível máximo anterior.
Em seguida, vem a verificação essencial antes da publicação:
Qual é o nome desta regra e a quais versões os consumidores estão vinculados?
Os consumidores vinculados à versão 3 permanecem inalterados. Aqueles configurados para usar a versão mais recente receberão a atualização quando você publicar. Para saber qual versão cada um utiliza, basta uma frase.
6. Crie a regra a partir do ticket que a solicitou
Antes: Um analista de negócios escreve a nova política de descontos em um ticket. Alguém a lê. Abre o DecisionRules. Transforma a política em uma tabela. Depois volta ao ticket e adiciona uma observação informando que a tarefa foi concluída.
Agora: As duas ferramentas estão conectadas ao mesmo assistente.
O ticket DRU-4730 acabou de chegar. Atualize a tabela de taxas de juros de acordo com o que ele solicita.
Transforme um ticket em uma atualização de regra testada sem sair do fluxo de trabalho.
O assistente lê o requisito da forma como a área de negócios o escreveu, atualiza a regra, executa os casos e fecha o ciclo no mesmo local em que a solicitação começou.
O que diferencia este caso dos outros cinco é que o DecisionRules não é a única ferramenta na conversa. O mesmo padrão funciona com uma planilha no lugar de um ticket, com um banco de dados como fonte de dados de referência ou com um canal do Slack como local onde o resultado é anunciado. Suas regras deixam de ser uma ilha que só pode ser aberta em sua própria aba.
O resultado de tudo isso
Nada disso é novo em termos de funcionalidade. Cada ação utiliza um recurso que já existe no DecisionRules. O assistente chama as mesmas ferramentas que você usaria.
O que o MCP elimina é a distância. A regra, a IA e a pessoa agora estão no mesmo lugar. O ciclo entre a ideia e a verificação é concluído em segundos, não em minutos.
Ivan Peresta trabalha na DecisionRules, onde seu papel abrange análise de produto, serviços profissionais e suporte ao cliente. Ele participa de todo o ciclo de vida das funcionalidades do produto, desde o design inicial e pensamento de UX até testes práticos, documentação e entrega voltada ao cliente. Seu trabalho faz a ponte entre o desenvolvimento do produto e as pessoas que realmente o utilizam, seja ajudando um cliente a projetar seu sistema de regras ou garantindo que um novo recurso seja lançado com orientações claras e exemplos funcionais.
