Como consultores de IA definem o escopo da substituição interna de um SaaS

Qualquer consultor que se preze define o escopo da substituição interna de um SaaS da mesma forma: dividindo cada ferramenta entre as partes que você pode ver e as partes que precisam estar corretas sempre. O SaaS (software que você aluga mensalmente) é composto principalmente por telas, fluxos de trabalho e relatórios sobre um núcleo menor de registros. A IA tornou a primeira metade barata de recriar. A segunda metade é onde os projetos de substituição morrem, e um bom escopo existe para medir quanto da sua fatura de assinatura realmente vive ali.

Veja como o escopo da substituição interna de um SaaS é construído, passo a passo, e a pergunta principal que decide a maior parte dele. (Os nomes dos fornecedores e os números da pesquisa abaixo estavam precisos no momento da publicação; trate os detalhes como um panorama do momento.)

O que o escopo da substituição de um SaaS realmente contém?

Um inventário de tarefas, não uma lista de recursos. O consultor lista cada tarefa que a ferramenta realiza, quem interage com cada uma e o que acontece quando o resultado está errado. Cadeias de aprovação, painéis e formulários vão para uma coluna. Movimentação financeira, contagem de estoque, impostos e registros de funcionários vão para outra. O entregável é esse mapa, uma classificação de risco por tarefa e uma lista de todos os sistemas aos quais a ferramenta está discretamente conectada.

A pergunta de classificação é o ponto central: se este resultado estivesse errado, como você descobriria e quanto isso custaria? Um painel desatualizado é percebido num piscar de olhos e não custa nada. Um total de pagamento incorreto é percebido na hora dos impostos e custa dinheiro de verdade.

Por que dividir o produto em duas camadas?

Porque a IA reduziu drasticamente o custo de uma camada e não mudou em nada a outra. A camada de interface (formulários, painéis, ferramentas internas, fluxos de aprovação) agora é rápida de recriar; os modelos atuais geram aplicações web funcionais em poucas horas, exatamente o que descobrimos quando perguntamos se o GPT-5.6 poderia criar um POS funcional. A camada de infraestrutura é diferente: processamento de pagamentos, conformidade com PCI (as regras de segurança de cartão exigidas pelos processadores), estoque simultâneo (dois caixas vendendo a mesma última unidade) e relatórios conciliados (totais que correspondem ao seu depósito bancário). Essa camada não é difícil porque o código é longo. É difícil porque o 'quase certo' não vale nada ali, e comprovar a exatidão custa mais do que gerar o código.

Modelos melhores também não eliminam essa restrição. O gargalo é a verificação e a responsabilidade, não a geração de código, por isso um escopo honesto precifica a verificação. A geração é a demonstração. A verificação é a fatura.

O que a substituição de SaaS da Klarna realmente provou?

A história mais alardeada de "substituímos nosso SaaS por IA" é, na verdade, uma lição sobre escopo. No final de 2024, o CEO da Klarna anunciou que a empresa estava abandonando o Salesforce e o Workday como parte de uma reformulação por IA, e as manchetes noticiaram que a IA estava substituindo o SaaS por completo. Reportagens posteriores revelaram algo mais limitado: a Klarna migrou o RH para outro fornecedor e atendeu às suas necessidades de CRM com uma combinação de ferramentas alternativas e integração interna, com IA sobreposta¹. Um banco licenciado operando um dos programas de IA mais agressivos do setor de fintechs ainda manteve seus sistemas de registro (a cópia autêntica dos dados do seu negócio) em plataformas comprovadas e recriou apenas as periferias.

Isso não foi falta de coragem. Foi o escopo funcionando.

Quais números justificam um projeto de substituição?

Primeiro elimine os desperdícios, depois crie. O 2026 SaaS Management Index da Zylo, baseado em mais de 40 milhões de licenças sob gestão, aponta um gasto mediano com SaaS de US$ 9.455 por funcionário ao ano, revela uma média de 36% de licenças não utilizadas e mostra que as unidades de negócio controlam 81% dos gastos com SaaS, enquanto a TI gerencia diretamente 15%². Um consultor classifica sua infraestrutura em relação a esses números antes de propor qualquer coisa: cancele as licenças não usadas, consolide as ferramentas sobrepostas e só então selecione os candidatos para recriação.

As ferramentas que entram na lista final compartilham o mesmo perfil: alto custo recorrente, tarefas concentradas principalmente na camada de interface e um pequeno raio de impacto quando algo falha. O projeto é aprovado quando o custo de assinatura cresce mais rápido do que o custo de desenvolvimento e manutenção, e todas as tarefas que exigem exatidão absoluta podem continuar em uma infraestrutura mantida por terceiros.

Onde o POS se encaixa nesse escopo?

Na ponta mais rigorosa do espectro. Um ponto de venda parece um projeto de interface — uma grade de botões e um carrinho —, então os proprietários presumem que seu escopo é semelhante ao de um painel. A proporção é inversa. A tela de checkout é apenas uma pequena parte do produto; o restante é processamento de pagamentos, hardware certificado para cartões físicos, controle de estoque simultâneo em dois caixas, regras fiscais e relatórios diários conciliados. Quando um POS erra, ele erra no dinheiro, todos os dias.

Portanto, os consultores definem o escopo da recriação de um POS da mesma forma que a Klarna definiu o de sua contabilidade: interface personalizada, infraestrutura comprovada. Essa divisão costumava exigir uma equipe de desenvolvedores. Agora é uma categoria de produto: o Build da Final transforma um prompt em linguagem natural em um fluxo de checkout para pré-visualizar e implantar, e você pode conectar sua própria IA via MCP para desenvolver sobre a mesma infraestrutura de comércio. Os pagamentos, estoque, relatórios e hardware permanecem na camada que já está verificada.

Afinal, como você deve definir o escopo para substituir um SaaS internamente?

Divida cada ferramenta em suas duas camadas, classifique cada tarefa pelo custo de um resultado incorreto não detectado e precifique a verificação, não o código. Recrie interfaces e fluxos de trabalho livremente; mantenha os sistemas de registro na infraestrutura mantida por terceiros. Antes de recriar qualquer ferramenta internamente, pergunte: se o resultado estivesse errado, quão rápido eu saberia? Se a resposta for "não muito rápido", essa tarefa deve continuar em uma estrutura comprovada.

E se a parte comercial da sua infraestrutura for o que você quer recriar, comece com uma análise sincera do que os modelos atuais podem e não podem construir sozinhos: Claude vs ChatGPT vs Gemini em uma criação real de POS, ou as duas rotas sem código em como usar o Gemini 3.6 Flash para criar um POS personalizado.