Soluções
Escolhemos processos onde o erro é medível e a reversão é possível.
Não recomendamos começar pelo processo mais crítico. Recomendamos começar pelo processo com volume alto, erro quantificável e impacto regulatório baixo — porque é aí que o retorno se prova depressa e o risco é contido.
Resposta a pedidos de cotação
Pedidos chegam a uma caixa genérica, alguém procura a tabela de preços, verifica o desconto aplicável e redige a resposta. O registo no CRM é irregular.
Como o Jinas o executa
Recuperação da política de preços com fonte citada, classificação do pedido, redação fundamentada, verificação determinística do limite de desconto e gate humano acima do limite de autonomia.
Onde para para revisão humana
Valor acima de 25 000 € ou desconto acima de 8% para revisão.
Conciliação de faturas de fornecedores
Faturas são confrontadas manualmente com ordens de compra e as divergências resolvem-se por email, sem registo consistente.
Como o Jinas o executa
Recuperação das regras de conciliação, explicação da divergência, tolerância avaliada por regra e escalamento para revisão financeira quando a diferença sai da tolerância.
Onde para para revisão humana
Divergência acima de 250 € ou fatura sem ordem de compra.
Onboarding de cliente
Recolha de documentação, criação de registos em três sistemas e agendamento da reunião de arranque, com passos que se perdem entre pessoas.
Como o Jinas o executa
Sequência com validação de completude documental antes de qualquer escrita, e ações separadas por sistema para que uma falha parcial seja visível no trace.
Onde para para revisão humana
Documentação incompleta interrompe antes de escrever em sistemas externos.
Triagem de pedidos de suporte
Volume alto, classificação inconsistente e tempo de primeira resposta dependente de quem está disponível.
Como o Jinas o executa
Classificação com limiar de confiança explícito; abaixo do limiar o pedido é encaminhado para uma pessoa em vez de receber uma etiqueta arriscada.
Onde para para revisão humana
Confiança abaixo do limiar configurado.
Piloto
O que medimos antes de expandir.
Um piloto que não define baseline não pode concluir nada. Estas são as métricas que o console recolhe automaticamente.
| Métrica | Porque importa |
|---|---|
| Horas humanas eliminadas por mês | Traduz-se diretamente em custo evitado, com o custo/hora declarado no processo. |
| Custo por execução | Tokens e chamadas de modelo atribuídos por passo; sem isto o retorno é uma estimativa. |
| Taxa de sucesso | Fração de execuções concluídas face ao total, incluindo falhas de regra. |
| Taxa de autonomia | Fração de execuções que não precisou de intervenção humana. |
| Execuções sem fundamentação | Detetadas pelo passo de validação; um output sem fonte é um defeito, não um estilo. |
| Tempo de ciclo | Duração da execução, comparável com o tempo manual do baseline. |
Onde não recomendamos começar
Ser explícito sobre os limites é parte da proposta.
Decisões reguladas
Crédito, saúde, elegibilidade e matérias com obrigação legal de fundamentação exigem um regime de governação próprio antes de qualquer automação.
Ações irreversíveis sem revisão
Pagamentos, comunicações contratuais e alterações de dados de terceiros devem ficar atrás de um gate, mesmo quando o modelo acerta.
Processos ainda não estabilizados
Se a regra muda todas as semanas, o problema é de desenho do processo. Automatizar primeiro apenas torna a instabilidade mais rápida.