--- title: "Quem mantém os fluxos depois do go-live: autonomia ou execução assistida" description: Quem mantém os fluxos depois do go-live? Veja o que cada modelo exige do time, o que fica com a VAAS e como mudar regras sem quebrar a produção. --- [Blog da VAAS | Seu guia completo para compliance, regulação e gestão de riscos](https://blog.vaas.com.br) # [Quem mantém os fluxos depois do go-live: autonomia ou execução assistida](https://blog.vaas.com.br/quem-mantém-os-fluxos-depois-do-go-live) Written by [Laura Levy](https://blog.vaas.com.br/author/laura-levy) | Oct 5, 2026, 12:47:57 PM Em toda negociação de plataforma de risco, TI e Compliance acabam fazendo a mesma pergunta: quem customiza os fluxos e quem cuida deles depois do go-live? A TI pergunta porque não quer herdar mais um sistema. O time já cuida de integrações com birôs, da esteira de onboarding e de regras espalhadas pelo código, e tem medo de que a configuração na mão da área de negócio vire sobrecarga para a tecnologia. Por isso muita TI acaba segurando essa demanda mesmo sem querer, e a fila vira uma forma de proteção. Para o Compliance, essa mesma fila é um bloqueio, porque cada ajuste de regra que depende de chamado é uma semana de exposição e menos controle sobre um processo pelo qual ele responde ao regulador. Cada um quer ouvir uma resposta diferente, mas a dor é a mesma: depender de uma área que tem outra prioridade. A seguir explicamos os dois modelos possíveis, o que cada um pede de cada área e o que precisa existir para que os dois sejam seguros. ## Em resumo Na prática são dois caminhos: ou o compliance mantém as regras direto na plataforma, sem código e sem chamado, ou a VAAS faz os ajustes a partir da política que vocês definem. Nos dois, a TI fica só com as integrações, a VAAS cuida da plataforma e qualquer ajuste é testado antes de ir para produção, com a opção de voltar atrás. | | **Cliente mantém** | **VAAS assume** | | --- | --- | --- | | O que exige do time | Um dono da política com tempo e critério para manter as regras | Especificar com clareza e validar com casos reais | | Quando quem sabe sai | O registro fica no editor e o raciocínio precisa estar documentado | A execução segue com o fornecedor e a política precisa estar documentada | | Resposta a incidente | No mesmo dia, sem fila | De algumas horas ao mesmo dia | | Carga para a TI | Só integrações | Só integrações |   ## Os dois modelos de sustentação ### Modelo 1: o cliente mantém, em low-code Regras, cenários e matrizes de risco ficam com o compliance no Workflow Builder, o editor da plataforma, e criar ou ajustar uma regra não pede código nem chamado. O que exige do time: alguém que conheça a política de risco, assuma a manutenção das regras e entenda por que cada critério existe, sem precisar ser técnico. Essa pessoa também precisa saber quando não mexer, porque fontes demais, regras complexas demais ou testes com poucos casos são o jeito mais comum de uma boa intenção piorar a operação. O resultado aparece em mais tempo de processamento, mais alertas para analisar e decisões mais difíceis de explicar na auditoria. **Quando a pessoa que sabe sai:** é o ponto que decide o modelo e quase ninguém pergunta. Com as regras no editor, quem chega vê o que existe, quem alterou e quando, mas se o raciocínio estava só na cabeça de quem configurou, ele vai embora junto. A plataforma guarda o registro, só não substitui uma política documentada. **Resposta a incidente:** no mesmo dia e sem fila. Se aparece uma tipologia nova, quem entende do risco ajusta, testa e publica. **Para a TI:** as regras saem do backlog e o medo de sobrecarga passa a ser resolvido com controle em vez de fila. Toda mudança é testada antes de publicar, o processamento roda na nuvem da VAAS e a TI segue dona das integrações, não do conteúdo da política. **Para o compliance:** controle total, junto com a responsabilidade. ### Modelo 2: a VAAS assume a configuração  A instituição define a política e o fornecedor cuida da implementação, dos ajustes e da manutenção.  **O que exige do time:** saber explicar o que precisa e validar o resultado com casos reais. Esse aceite não pode ser formalidade, porque é nele que vocês confirmam que o que foi configurado é o que vocês quiseram dizer. **Quando a pessoa que sabe sai:**  o risco muda de lugar. A configuração continua registrada e a execução não depende de ninguém de dentro, mas aparece outro risco, o de a especificação ser entendida de outro jeito e a regra ir para produção com esse desvio. A proteção é ter a política bem documentada e validar antes de publicar, e é essa documentação que evita que o próximo pedido de ajuste parta de uma interpretação.  **Resposta a incidente:** de algumas horas ao mesmo dia, dependendo da complexidade. A velocidade passa a ser a da fila do fornecedor, que é curta mas existe, então vale combinar um prazo para urgências já na implantação. **Para a TI:**  nada além das integrações que já estavam planejadas, e sustentação e performance ficam com o fornecedor.  **Para o compliance:** a decisão continua sendo sua, mas a execução não, e isso pesa se a política muda toda semana. ## O que a VAAS assume em qualquer cenário Seja qual for o modelo, a VAAS cuida da performance e da estabilidade da plataforma, faz a implantação inicial com fluxos, matriz de risco e integrações e, em geral, assume os ajustes estruturais, como incluir uma fonte de dados nova ou redesenhar um fluxo. Como esses ajustes são os que mais mexem com desempenho e volume, eles pedem a participação da VAAS mesmo no modelo interno. No modelo assistido os ajustes do dia a dia também ficam com a gente, e a única coisa que nunca sai da instituição é a definição da política de risco. Dá ainda para combinar os dois modelos. O que funciona é dividir por frequência, e não por complexidade: o que muda toda semana fica com quem decide e o que muda uma vez por trimestre pode ficar com o fornecedor. ## O que torna a manutenção segura Antes de decidir quem mantém, vale responder outra pergunta: mexer na configuração pode quebrar o que está em produção? Se puder, nenhum dos modelos é seguro, e são quatro mecanismos que evitam isso. **Teste antes da publicação:** Um comprador contou que, no sistema que usava, cada deploy apagava os rascunhos de regra do compliance sem aviso e sem como recuperar, porque não havia separação entre o que estava em construção e o que estava em produção. Na plataforma, regras e workflows são testados antes e a produção só muda quando alguém publica. O teste só protege se for bem dimensionado, já que poucos casos não mostram como a regra se comporta no volume real. **Versionamento:** Toda versão publicada fica registrada e cada decisão guarda a versão da regra que a gerou, então dá para saber qual regra estava no ar em qualquer data, uma pergunta comum em auditoria. **Usuário administrador e acessos nominais:** Cada pessoa entra com o próprio usuário e um perfil administrador define quem pode alterar e publicar. Assim fica a trilha de quem mudou o quê, e a TI participa da definição de quem publica sem ter que executar cada alteração. **Reversão:** Dá para voltar à versão anterior sem reconstruir nada, e é isso que faz um erro de configuração durar minutos em vez do tempo de refazer tudo do zero. Com esses mecanismos, os riscos de cada modelo ficam sob controle e a escolha passa a ser uma questão de operação. Teste e reversão protegem tanto contra a regra mal calibrada pelo time quanto contra a regra mal traduzida pelo fornecedor. ## “Não temos braço para implementar” e “vamos precisar de um recurso dedicado” Essas duas objeções costumam aparecer juntas e são as que mais adiam a decisão. A resposta está em separar o esforço de começar do esforço de manter. **A VAAS faz a implantação e os ajustes:** Fluxos, matriz de risco e integrações são configurados pela VAAS, e a instituição só define a política e valida o resultado com casos reais. Se depois do go-live ninguém assumir a manutenção, os ajustes continuam no modelo assistido. **Dá para começar antes de integrar:** O compliance já usa a plataforma direto, e a integração com os sistemas internos entra quando couber no roadmap de tecnologia. Isso tira o projeto da fila de desenvolvimento, que é o que normalmente empurra a decisão para o trimestre seguinte, e a plataforma não entra no backlog da TI logo no primeiro dia. **Recurso dedicado não é pré-requisito:** Analisar casos e revisar alertas é o que o time já faz hoje, só que agora numa tela só. Um responsável dedicado só faz sentido se vocês mantiverem as regras e a política mudar com muita frequência, e mesmo assim costuma ser alguém do time atual, não uma contratação nova. ## **Três perguntas para decidir o modelo** Vale fazer estas perguntas com TI e Compliance na mesma sala. 1. **Quem vai ser dono da política configurada?** Se a resposta tem nome, manter internamente é viável. Se não tem, o caminho honesto é começar no modelo assistido e fazer a transição depois. 2. **Com que frequência a política de risco muda?** Se muda toda semana, vale ter autonomia. Se muda a cada trimestre, não precisa. 3. **O que fica registrado se quem configurou sair?** Faça essa pergunta a qualquer fornecedor. A resposta que interessa fala de histórico, versionamento e documentação, e não de reter pessoas. Autonomia, aqui, é ter o controle à mão sem precisar carregar tudo sozinho. ## **Perguntas frequentes** ### **Quem customiza a plataforma: nós ou vocês?** Na implantação somos nós. Depois do go-live, isso pode ficar com o seu time no Workflow Builder ou continuar com a gente, dependendo de ter alguém interno disposto a ser dono das regras. ### **Como mantenho os fluxos depois da implantação?** Ou o seu time ajusta, testa e publica direto no editor, ou a gente faz os ajustes a partir da política de vocês. Em qualquer caso, toda alteração fica versionada e pode ser revertida. ### **E se precisarmos alterar uma política com urgência?** Pode acontecer por causa de uma norma com vigência imediata, uma fraude em curso ou um apontamento de auditoria. No modelo interno o seu time resolve no mesmo dia, e no assistido vale o prazo combinado na implantação. O ideal é deixar claro desde o começo o que conta como urgente, quem pode pedir e em quanto tempo a mudança entra em produção. Se urgência é algo frequente na operação, o modelo híbrido costuma funcionar melhor, com o seu time ajustando as regras e a gente cuidando do que é estrutural. ### **Não temos equipe para implementar. Isso inviabiliza?** Não. Quem faz a implantação somos nós, e a plataforma pode ser usada antes de qualquer integração, então o seu time só precisa definir a política e validar o resultado. ### **Precisamos de um recurso dedicado para operar a plataforma?** Para começar, não. Só faz sentido se vocês decidirem manter as regras internamente e a política mudar com muita frequência. ### **Se alguém alterar uma regra, a produção pode quebrar?** Pode, se a mudança for mal calibrada, e é justamente por isso que a regra é testada antes, só entra em produção quando alguém publica e pode voltar para a versão anterior. O que nenhuma ferramenta resolve é um teste feito com poucos casos. ### **Se o compliance configurar sozinho, isso sobrecarrega a TI?** O medo da TI costuma ser uma mudança ir direto para produção e o problema aparecer depois. Como a regra é testada antes de publicar, o processamento roda na nossa nuvem e as integrações continuam com a TI, esse risco fica sob controle. O recomendado é combinar entre as duas áreas, já na implantação, quem pode publicar e quais mudanças passam por avaliação técnica. ### **E se a pessoa que configurou os fluxos sair da empresa?** As regras continuam no editor, com o histórico de quem alterou o quê e quando. O que a plataforma não substitui é a política de risco documentada, que segue sendo responsabilidade de vocês. ## **Sustentação faz parte do produto** Na VAAS, a sustentação faz parte do produto: a implantação é conduzida pelo nosso time, a performance da plataforma é responsabilidade nossa e o modelo de manutenção é escolha de vocês, podendo mudar conforme o time amadurece. Assim a TI não herda mais um sistema, o compliance para de depender de chamado para mudar uma regra e cada alteração fica registrada para quando a auditoria perguntar. ### **Ainda não sabe qual modelo cabe na sua operação?** Traga TI e Compliance para essa conversa, fale com a gente ou acesse nosso site.   [View full post](https://blog.vaas.com.br/quem-mantém-os-fluxos-depois-do-go-live) ```json { "@context" : "http://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "Laura Levy" }, "dateModified" : "2026-10-07T19:38:41.371Z", "datePublished" : "2026-10-05T12:47:57Z", "headline" : "Quem mantém os fluxos depois do go-live: autonomia ou execução assistida", "image" : { "@type" : "ImageObject", "height" : 1080, "url" : "https://43851301.fs1.hubspotusercontent-na1.net/hubfs/43851301/ob%20%282%29-1.png", "width" : 1920 }, "mainEntityOfPage" : "https://blog.vaas.com.br/quem-mantém-os-fluxos-depois-do-go-live", "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "height" : 60, "url" : "/hs/hsstatic/content_shared_assets/static-1.4092/img/default-amp-logo.png", "width" : 60 }, "name" : "Seu guia completo para compliance, regulação e gestão de riscos" } } ```