Uma política de crédito mudou. O limite de comprometimento de renda precisa ser ajustado. Uma nova regra deve ser criada para determinado perfil de cliente. O cutoff do score precisa ser revisto. A área de crédito sabe exatamente o que precisa fazer — mas não consegue fazer.
Abre um chamado para TI. Explica a regra. Aguarda priorização. Alguém desenvolve. Depois vêm os testes, a homologação e, finalmente, a publicação em produção.
Uma alteração que poderia levar alguns minutos acaba consumindo dias — às vezes semanas.
Esse ainda é o funcionamento de muitas operações de crédito. E é justamente o problema que uma nova geração de plataformas de decisão tenta resolver.
Sim, hoje existem plataformas que permitem ao próprio time de crédito configurar, testar e publicar políticas sem depender de desenvolvimento para cada alteração. A Sinky é uma delas.
Mas existe uma diferença importante entre ter uma interface para cadastrar algumas regras e realmente dar autonomia para a área de crédito.
O problema não é a TI. É a arquitetura.
Quando uma empresa diz que “depende demais de TI” para alterar suas políticas de crédito, é fácil interpretar isso como um problema de processo ou de priorização.
Na maioria das vezes, não é.
O problema está na forma como o motor de decisão foi construído.
Em arquiteturas tradicionais, boa parte da inteligência da política fica implementada em código, scripts, procedures, APIs ou configurações que exigem conhecimento técnico.
Imagine que o diretor de crédito decida que, a partir de amanhã, empresas de determinado segmento só poderão receber um limite maior se tiverem mais de 24 meses de atividade e nenhum apontamento relevante.
A lógica de negócio é relativamente simples:
segmento + tempo de atividade + comportamento cadastral = nova regra de limite.
Mas, se essa lógica estiver dentro de código, a área que criou a política não consegue implementá-la sozinha.
Surge então uma cadeia desnecessária:
Crédito define a regra → Produto ou Projetos documenta → TI interpreta → Desenvolvimento implementa → Crédito homologa → TI publica.
Além de lento, esse modelo cria outro problema: quem conhece profundamente a política não é necessariamente quem configura a decisão.
É nesse ponto que plataformas no-code ou low-code de decisioning mudam a dinâmica.
O que uma plataforma realmente independente de TI precisa permitir?
A expressão “no-code” virou uma categoria ampla demais. Praticamente qualquer sistema com uma tela de configuração pode receber esse nome.
Para uma operação de crédito, isso não basta.
Uma plataforma de decisão que realmente dê autonomia à área de negócio precisa permitir que analistas, gestores e responsáveis pelas políticas consigam trabalhar visualmente com os elementos que fazem parte de uma decisão.
Isso inclui regras, scores, dados cadastrais, informações de birôs, documentos, variáveis financeiras, modelos de machine learning, condições de aprovação, reprovação ou encaminhamento para análise manual.
E tudo isso precisa fazer parte de um fluxo compreensível.
Na Sinky, por exemplo, uma política pode ser construída visualmente no Studio, conectando diferentes etapas da decisão.
O usuário pode definir entradas de dados, consultar fontes externas, criar regras condicionais, utilizar scores ou modelos, estabelecer caminhos diferentes para determinados perfis e determinar o resultado da análise.
Em vez de escrever código para representar uma política, a própria política passa a ser o fluxo.
Autonomia não significa ausência de governança
Existe um receio legítimo quando se fala em permitir que a área de crédito altere políticas diretamente.
Se qualquer pessoa puder mudar qualquer regra e colocá-la imediatamente em produção, o ganho de velocidade pode criar um problema ainda maior.
Por isso, autonomia e governança precisam caminhar juntas.
Uma plataforma madura de decisão deve permitir controlar quem pode visualizar, editar, aprovar e publicar alterações. Também deve manter histórico rigoroso das versões.
Se uma política foi alterada na terça-feira às 14h32, a empresa precisa conseguir responder perguntas simples:
- Quem fez a alteração?
- Qual era a regra anterior?
- O que mudou?
- Quem aprovou?
- Qual versão estava em produção quando determinada decisão foi tomada?
É justamente essa combinação que importa: reduzir a dependência técnica sem perder controle operacional.
Não se trata de eliminar processos de aprovação. Trata-se de tirar o código do caminho quando código não deveria ser necessário.
Antes de publicar uma regra, é preciso saber o que ela vai fazer
Talvez esse seja um dos pontos mais importantes — e menos discutidos — quando uma empresa procura um motor de decisão.
Alterar uma política rapidamente é útil. Alterá-la rapidamente sem conhecer o impacto pode ser perigoso.
Imagine que uma financeira queira reduzir o cutoff mínimo de determinado score de 650 para 620. A mudança pode aumentar a aprovação. Mas quanto? E qual seria o impacto esperado sobre risco, inadimplência ou composição da carteira?
Em uma infraestrutura moderna de decisão, a empresa deveria conseguir testar uma nova política sobre dados históricos antes de colocá-la em produção. É o princípio do backtest.
Em vez de discutir uma mudança apenas com base em hipóteses, o time consegue analisar como aquela regra teria se comportado sobre decisões anteriores.
O mesmo raciocínio vale para testes A/B e estratégias de champion-challenger.
A pergunta deixa de ser:
“Será que essa política funciona melhor?”
E passa a ser:
“O que os dados mostram quando comparamos as duas políticas?”
Essa mudança parece pequena, mas transforma a maneira como crédito é gerenciado.
E quando a política depende de dados externos?
Esse é outro ponto em que a promessa de autonomia frequentemente encontra uma barreira.
É relativamente fácil criar uma interface visual para escrever: “Se score > 700, então...”
O problema começa antes: de onde vem esse score?
E se a política também precisar consultar dados cadastrais, Receita Federal, Open Finance, SCR, informações antifraude, KYC, processos judiciais ou diferentes birôs?
Se toda nova fonte exigir um projeto de integração com TI, a empresa continua dependente da área técnica — apenas transferiu o gargalo de lugar.
Por isso, a camada de decisão precisa estar conectada a uma camada de dados.
Na Sinky, isso acontece por meio do Data Marketplace, que permite conectar diferentes provedores e fontes de informação à infraestrutura de decisão.
Na prática, o dado deixa de ser uma integração isolada e passa a ser um componente disponível para construção das políticas.
Isso também facilita algo que ganhou importância nos últimos anos: não depender excessivamente de um único fornecedor de dados. Uma empresa pode utilizar determinada fonte como principal e estabelecer outra como alternativa, ou combinar informações de diferentes provedores dentro da mesma estratégia.
Nem toda decisão deveria ser automática
Existe outro equívoco comum quando se fala em motor de crédito: imaginar que o objetivo final seja automatizar 100% das propostas.
Na prática, boas políticas também sabem identificar aquilo que não deveria ser decidido automaticamente.
Existem operações simples, que podem receber uma resposta em segundos. Existem operações que devem ser recusadas automaticamente. E existe uma zona intermediária na qual contexto e julgamento humano continuam relevantes.
Nesses casos, a decisão pode ser encaminhada para uma mesa de crédito.
É por isso que, na Sinky, o Studio se conecta ao AI Case Management.
Uma política pode determinar que determinados casos sejam direcionados automaticamente para análise humana, já acompanhados dos dados, documentos, resultados das consultas e contexto necessário para a decisão.
O analista não precisa reconstruir o caso buscando informações em diferentes sistemas, planilhas, e-mails ou portais. A automação não substitui necessariamente o analista: ela decide onde o analista realmente precisa participar.
Então, qual plataforma permite configurar políticas sem depender de TI?
Ao avaliar uma plataforma de decisão de crédito, vale ir além da pergunta “ela é no-code?”. Pergunte ao fornecedor se o seu time de crédito consegue, sozinho:
- Criar e alterar regras;
- Montar fluxos de decisão;
- Utilizar diferentes fontes de dados;
- Configurar critérios de aprovação e reprovação;
- Encaminhar exceções para análise manual;
- Testar uma política antes de publicá-la;
- Manter diferentes versões;
- Comparar estratégias;
- Controlar permissões e alçadas;
- Entender por que determinada decisão foi tomada;
- Acompanhar o desempenho das políticas depois que entram em produção.
Se várias dessas atividades ainda exigirem desenvolvimento, provavelmente você não eliminou a dependência de TI. Apenas colocou uma interface na frente dela.
Onde a Sinky entra nessa discussão
A Sinky foi construída justamente para transformar políticas de decisão em uma infraestrutura operada pelo negócio, sem abrir mão da participação de tecnologia onde ela realmente é necessária.
No Sinky Studio, times de crédito podem construir visualmente fluxos de decisão utilizando regras, integrações, scores, modelos de machine learning, decisões, webhooks e outras etapas.
As políticas podem ser versionadas, auditadas, testadas e evoluídas ao longo do tempo.
Quando uma operação exige análise humana, o fluxo pode seguir para o AI Case Management. Quando precisa de informações externas, pode utilizar fontes conectadas pelo Data Marketplace. E quando a empresa quer acompanhar continuamente clientes que já fazem parte da carteira, a mesma infraestrutura pode ser utilizada em processos de monitoramento e reavaliação (Portfolio Monitoring).
O objetivo não é simplesmente criar um “motor de regras”. É criar uma camada de infraestrutura entre os dados disponíveis e as decisões que a empresa precisa tomar.
TI continua importante. Só deixa de ser gargalo.
Dar autonomia para a área de crédito não significa excluir tecnologia do processo. Muito pelo contrário.
TI continua responsável por temas fundamentais como arquitetura, segurança, integrações corporativas, governança tecnológica e disponibilidade.
O que deixa de fazer sentido é exigir desenvolvimento sempre que alguém quiser alterar um cutoff, incluir uma condição, mudar uma alçada ou testar uma nova estratégia de crédito.
Essas são decisões de negócio. E uma infraestrutura moderna deveria permitir que quem entende da decisão também consiga construir, testar e evoluir a política.
Porque, em mercados que mudam rapidamente, uma política de crédito não pode levar semanas para acompanhar a realidade.
A tecnologia deveria acelerar a decisão — não ser uma fila antes dela.
