IA redistribui tarefas em equipes de TI: o que o caso da Multipagamentos ensina sobre governança

A Multipagamentos, empresa de tecnologia para meios de pagamento, colocou em operação desde julho de 2026 um modelo formal de uso de inteligência artificial dentro do ciclo de desenvolvimento de software. O caso, relatado pela revista PEGN (Pequenas Empresas & Grandes Negócios), interessa menos pelo anúncio em si e mais pelo que ele revela sobre o custo real de levar modelos de linguagem para dentro de um pipeline de produção que lida com dados de pagamento.

O ponto central não é a geração de código. É a camada de governança que a empresa precisou construir ao redor dela, e que qualquer time de TI que for pelo mesmo caminho vai ter que reproduzir, com seus próprios recursos.

O que mudou antes da primeira linha de código ser escrita

Na Multipagamentos, a IA entrou primeiro na etapa de levantamento de requisitos, não na escrita de código. Pedidos que antes chegavam por reunião, e-mail, documento e mensagem avulsa passaram a ser consolidados e estruturados por modelos de linguagem, que identificam lacunas na demanda e a transformam em um formato padronizado para o time técnico.

Em seguida, a mesma camada de IA decompõe a demanda em etapas de desenvolvimento, critérios de aceite, cenários de exceção e componentes do sistema que podem ser impactados. Em um dos fluxos citados pela empresa, essa preparação inicial leva cerca de 90 minutos. É o único número concreto de tempo que a empresa divulgou até agora.

A Multipagamentos não converteu esse ganho em percentual de produtividade. Segundo a reportagem, a adoção é recente demais e não havia base histórica estruturada o suficiente para comparação antes e depois. Para quem avalia investir em ferramenta parecida, isso é um dado tão relevante quanto o resultado em si: sem linha de base medida antes da mudança, qualquer número de ganho de produtividade divulgado por um fornecedor três meses depois do início da adoção merece ceticismo.

Como a aprovação de código muda quando parte dele vem de IA

Antes, a revisão de código na empresa era basicamente conferência entre pares sobre trechos escritos por humanos. Com IA gerando parte do código, o processo de aprovação ganhou camadas:

• classificação das ferramentas de IA por nível de risco;
• limites de acesso definidos conforme essa classificação;
• verificações específicas para aplicações construídas com modelos de linguagem;
• aprovação humana nominal, ou seja, identificada por pessoa responsável;
• auditoria feita pela liderança de tecnologia.

Nenhum código com apoio de IA chega à produção sem essa aprovação identificada. Em ambientes produtivos, os acessos usados para diagnóstico são restritos e de leitura, sem acesso a dados de portador de cartão, o tipo de informação mais sensível que a empresa manipula.

Essa arquitetura de permissões é o que separa um experimento de copiloto de código de um uso estrutural em ambiente regulado. Quem decide adotar IA generativa em pipeline de pagamento, saúde ou qualquer setor com exigência de compliance vai precisar de desenho equivalente: não dá para liberar acesso de escrita ou execução para a ferramenta sem antes mapear o que ela pode ver e o que pode alterar.

Quanto mais a inteligência artificial participa da produção inicial, mais importante se torna a capacidade humana de verificar o resultado. O papel do desenvolvedor não desaparece, mas passa a exigir mais contexto, revisão, arquitetura, análise de risco e responsabilidade sobre aquilo que efetivamente chega à produção.

José Tadeu Bijos, CEO e presidente da Multipagamentos

O trabalho não desaparece, ele migra dentro do time

O efeito prático descrito pela empresa é um deslocamento de esforço, não uma redução de trabalho. Parte do que antes era tempo de produção inicial de código vira tempo de contextualização, arquitetura, revisão, validação e decisão técnica. Quem refina demandas também passa a dedicar mais energia a regra de negócio, exceção e qualidade, enquanto a IA assume consolidação, estruturação e documentação.

Para um gestor de TI que está desenhando a adoção de ferramentas de IA generativa no próprio time, esse deslocamento tem um custo que raramente aparece na conta de licença de software: treinar quem antes só escrevia código para também revisar com rigor o que a IA produziu, e criar papéis novos dentro da equipe para distribuir essa responsabilidade. A Multipagamentos fez isso formalmente, com papéis específicos e um programa de capacitação estruturado a partir de encontros internos chamados MultiCamps, usados para mapear onde a IA poderia ser aplicada e redesenhar processos.

Em resumo: o ganho de velocidade na geração de código é compensado, ao menos nesta fase inicial, pelo custo de montar a estrutura de revisão e governança que torna esse código seguro para produção. Quem avalia a adoção só pelo tempo que a IA economiza na escrita está olhando metade da equação.

O que ainda falta medir, e por que isso importa para quem decide investir

A empresa está construindo agora, não antes, os indicadores para medir o impacto real da mudança: telemetria das ferramentas de IA, identificação da origem de cada trecho de código (se foi gerado por IA, revisado por humano ou escrito do zero) e critérios para acompanhar produtividade, qualidade e retrabalho ao longo do tempo.

Isso é relevante porque inverte a ordem que normalmente se espera de um caso de adoção de IA: primeiro vieram o processo e a governança, só depois vem a métrica que comprova o ganho. Para quem está no papel de decidir orçamento e prioridade de TI, o recado prático é que validar o retorno sobre investimento em IA para desenvolvimento pode levar meses além da implantação, e que medir origem do código (humano, IA ou híbrido) precisa ser parte do desenho desde o primeiro dia, não um relatório pedido depois que o time já está usando a ferramenta no dia a dia.

O caso da Multipagamentos também deixa claro o que não vale a pena fazer: liberar ferramenta de geração de código para o time sem antes decidir que dados ela acessa, quem aprova o que ela produz e quem responde se algo falhar em produção. Em um negócio de meios de pagamento, essa decisão não é opcional, mas o raciocínio se aplica a qualquer sistema que lide com dado sensível de cliente, financeiro ou de saúde.

Fonte: Pequenas Empresas & Grandes Negócios