Imagine uma reunião de orçamento em que alguém apresenta um protótipo criado com inteligência artificial. Ele reproduz formulários, organiza informações e executa uma rotina semelhante à de uma aplicação contratada pela empresa. A pergunta surge quase naturalmente: se conseguimos construir isso com tão pouco esforço, por que continuamos pagando pelo software? Eu considero a pergunta legítima. O problema está em respondê-la antes de verificar se estamos comparando duas operações equivalentes ou apenas duas demonstrações visualmente parecidas.
É nessa diferença que situo minha leitura do chamado SaaSpocalypse. Não vejo uma escolha binária entre preservar os fornecedores atuais e substituí-los por agentes. Vejo a possibilidade de desmontar o pacote que aprendemos a comprar como software e examinar separadamente suas funções: interação, conhecimento de negócio, coordenação, execução e sustentação. Algumas poderão ser reproduzidas com vantagem; outras ganharão importância; outras deixarão de justificar a existência de um produto independente. A transformação merece atenção justamente porque pode ser profunda sem significar o desaparecimento do SaaS.
SaaS não é sinônimo de tela nem de licença por usuário
Software as a Service é um modelo de disponibilização de aplicações operadas pelo fornecedor em infraestrutura de nuvem. Sua definição técnica admite tanto o acesso por uma interface humana quanto por uma interface de programação. Não exige uma tela específica nem estabelece que a remuneração deva ocorrer por usuário. Portanto, trocar a navegação humana pelo acionamento de serviços por um agente não encerra, por si só, esse modelo. Podemos mudar a experiência, a arquitetura e a forma de cobrança enquanto continuamos consumindo software como serviço.
Essa distinção impede um erro estratégico: confundir a transformação de uma embalagem comercial com o desaparecimento da necessidade atendida. Uma empresa continuará precisando saber qual pedido é válido, que compromisso assumiu e quem pode modificá-lo. A pergunta em aberto é onde essas responsabilidades serão implementadas, quem as operará e quanto custará mantê-las. Não há garantia de que o fornecedor atual será a melhor resposta, mas também não há razão técnica para presumir que um modelo de linguagem substituirá sozinho todo esse conjunto.
Por isso, eu analisaria cada aplicação pela relação entre a facilidade de reconstruir suas funções e o custo de assumir suas responsabilidades. Uma ferramenta de escopo estreito, com regras simples e poucas dependências, pode ser uma candidata plausível à substituição. Outra, aparentemente semelhante na tela, pode participar de compromissos operacionais difíceis de reproduzir. O tamanho do fornecedor ou a familiaridade da marca não resolvem essa avaliação; a unidade de análise deveria ser o trabalho que precisa continuar funcionando.
Produzir código e sustentar uma operação são decisões diferentes
Mesmo quando a IA reduz o esforço de construir uma funcionalidade, permanece necessário verificar seu comportamento, proteger acessos, corrigir vulnerabilidades e acompanhar mudanças nas dependências. O desenvolvimento seguro é um ciclo de práticas, não uma condição alcançada no momento em que o código é gerado. É essa continuidade que estruturas como o Secure Software Development Framework ajudam a explicitar. Gerar uma aplicação não elimina o trabalho de mantê-la adequada ao uso.
Na avaliação de um investimento, eu incluiria também migração de dados, compatibilidade com integrações, recuperação de falhas, suporte e capacidade de evolução. Ao encerrar uma assinatura, a empresa pode reduzir uma despesa e incorporar responsabilidades antes executadas por terceiros. Isso pode ser uma excelente decisão, sobretudo quando existe diferenciação estratégica no que será construído. Mas precisa aparecer na análise econômica como transferência de trabalho e risco, não como economia automática.
Há uma consequência menos confortável para os dois lados. O comprador não pode comparar o custo de um protótipo com o de uma operação sustentada; o fornecedor, por sua vez, não pode invocar complexidade para justificar indefinidamente um preço. Se novas tecnologias permitirem oferecer a mesma capacidade com confiabilidade equivalente e menor custo total, o argumento histórico perde força. A permanência do SaaS como modelo não protege cada produto nem preserva suas margens.
A arquitetura passa a separar intenção, interpretação e execução
Para entender tecnicamente a mudança, eu separo três responsabilidades. A interação é onde alguém expressa o que precisa. A interpretação transforma essa solicitação em um encaminhamento, identificando dados e ações pertinentes. A execução valida e realiza as operações, preservando os registros que representam o estado do negócio. Essas responsabilidades podem continuar reunidas em uma plataforma ou ser distribuídas entre componentes diferentes. O ponto não é exigir separação total, mas deixar de presumir que precisam ser compradas como um bloco indivisível.
APIs tornam operações acessíveis a outros softwares, e especificações como OpenAPI permitem descrever esse acesso. O MCP, ou Model Context Protocol, padroniza a exposição de ferramentas que aplicações de IA podem descobrir e acionar. Esses mecanismos ajudam a conectar interpretação e execução, mas não criam as regras do negócio nem garantem o resultado do processo. Uma ferramenta apresentada ao agente pode continuar dependendo de serviços existentes para consultar um registro ou efetivar uma alteração.
A consequência é que um agente pode coordenar trabalho distribuído sem que todos os sistemas sejam reconstruídos. Também pode substituir uma camada intermediária que perdeu utilidade. Eu evitaria, contudo, transformar essa possibilidade em uma divisão eterna na qual modelos apenas interpretam e plataformas tradicionais sempre executam. Novos fornecedores podem desenvolver execução, enquanto aplicações estabelecidas podem incorporar inteligência. A arquitetura admite diferentes combinações; o desempenho econômico de cada uma dependerá do que consegue entregar e assumir.
Isso ajuda a compreender o sentido de combinar modelos e plataformas empresariais. A complementaridade está entre competências, não entre categorias condenadas a ocupar o mesmo lugar para sempre. A escolha relevante é como distribuir essas competências sem perder a continuidade do processo ou multiplicar o custo de coordená-las.
A inteligência sugere; a operação precisa confirmar
Considere um cancelamento de pedido. Um agente pode compreender o motivo, verificar uma política e propor uma solução. Para concluir, porém, o sistema precisa confirmar se o pedido ainda pode ser cancelado, se houve cobrança e se outra pessoa já iniciou a mesma operação. O histórico de uma conversa não deveria substituir o registro atualizado do negócio. Quando duas ações disputam os mesmos dados, mecanismos de controle de concorrência e isolamento de transações ajudam a preservar a integridade; a qualidade da resposta do modelo não oferece essa garantia.
Se a solicitação for reenviada depois de uma falha de comunicação, o desenho deve evitar um segundo reembolso indevido. Essa é a finalidade da idempotência nesse contexto: permitir repetir uma solicitação sem duplicar seu efeito de negócio. Quando o processo atravessa vários sistemas e uma etapa falha, pode ser necessário executar ações compensatórias. Compensar não significa sempre restaurar exatamente a situação anterior; algumas consequências exigem tratamento específico ou intervenção humana. Essas propriedades precisam ser implementadas e testadas, não inferidas da existência de um agente.
Da mesma forma, eu não deixaria a autorização de uma operação sensível a cargo exclusivo do raciocínio do modelo. As permissões devem ser verificadas nos sistemas que executam as ações, com limites proporcionais à tarefa e aprovação humana quando necessária. As orientações de segurança para agentes tratam justamente do risco de combinar ferramentas amplas, privilégios excessivos e autonomia indevida. Uma recomendação bem formulada não equivale a uma autorização válida.
É aqui que vejo uma oportunidade de diferenciação para o software empresarial: oferecer capacidades cujo resultado possa ser verificado. “Cancelar um pedido” precisaria ter condições de entrada, regras de autorização, um estado final identificável e evidências do que ocorreu. Chamo isso de um contrato de capacidade, no sentido técnico e operacional. Não basta disponibilizar uma função; é preciso tornar explícito o que ela promete, o que não promete e como a empresa saberá se o compromisso foi cumprido.
A nova conta não cabe apenas na linha de licenças
Quando agentes passam a realizar parte do trabalho, número de pessoas e volume de utilização podem seguir trajetórias diferentes. Uma equipe menor pode acionar mais operações, e uma interface pouco visitada pode sustentar uma atividade intensa. Na minha leitura, isso pressiona contratos vinculados exclusivamente a usuários, mas não determina a extinção dessa modalidade. A cobrança pode combinar acesso, capacidade reservada, consumo e resultados. O critério deveria ser a correspondência entre o que se remunera e o valor recebido, não a novidade do modelo comercial.
A execução com IA também acrescenta componentes de custo que precisam ser acompanhados: processamento dos modelos, uso de ferramentas e infraestrutura, além das escolhas de desenho que influenciam a quantidade de chamadas. A gestão de custos de IA reconhece essa diversidade e a necessidade de relacionar consumo a objetivos de negócio. Um agente que repete tentativas ou utiliza um modelo mais caro do que a tarefa exige pode elevar a despesa sem melhorar proporcionalmente o resultado.
Essa pressão sobre custos também orienta escolhas de engenharia. Eu não colocaria raciocínio generativo em cada etapa de um fluxo quando uma regra explícita resolve a tarefa. A IA pode interpretar a solicitação e tratar situações variáveis, enquanto serviços convencionais executam operações bem definidas. Para quem vende a solução, essa composição pode ser decisiva: aumentar a receita por tarefa não assegura margem se cada conclusão exigir processamento e intervenção desproporcionais. A eficiência da arquitetura passa a integrar o desenho do produto e do preço.
Eu levaria ao CFO o custo por processo concluído corretamente, não apenas o preço da licença ou do token. Para calculá-lo, somaria os custos atribuíveis à jornada – software, processamento, integração, supervisão, suporte e correção – e dividiria pelas conclusões válidas no mesmo período. Essa leitura está alinhada à distinção entre métricas de eficiência de recursos e métricas econômicas do negócio. O cuidado é comparar jornadas com escopo, qualidade e níveis de serviço equivalentes. Também acompanharia taxa de sucesso, cobertura e retrabalho, para não premiar uma solução que pareça barata apenas porque evita os casos difíceis.
Essa medida também impede uma ilusão importante. Reduzir o custo por operação não significa reduzir o desembolso total se o volume crescer mais rapidamente. O aumento da despesa pode ser desejável quando vem acompanhado de receita, capacidade útil ou melhor atendimento, mas não deveria ser vendido como economia de caixa. Da mesma forma, horas liberadas só se convertem em benefício financeiro conforme sejam aproveitadas: para atender demanda adicional, evitar contratações, melhorar resultados ou retirar efetivamente custos. Eu exigiria que o caso de negócio distinguisse essas trajetórias.
Cobrar por resultado tampouco resolve sozinho o alinhamento de incentivos. Um atendimento encerrado pode não ter resolvido o problema; um pedido processado pode exigir correção posterior. Antes de contratar, eu definiria o que conta como conclusão, por quanto tempo ela será observada e como exceções e retrabalho serão tratados. Para o fornecedor, assumir essa remuneração também significa avaliar quanto do resultado controla. Prometer um desfecho que depende de dados ruins ou de terceiros indisponíveis pode transformar uma oferta atraente em uma operação economicamente frágil.
O valor pode permanecer, enquanto o poder de negociação muda
Um software pode continuar tecnicamente necessário e perder capacidade de capturar valor. Se passa a executar uma operação padronizada, facilmente substituível por alternativas equivalentes, sua importância operacional não garante diferenciação econômica. Em sentido inverso, uma aplicação especializada pode manter relevância ao incorporar conhecimento de domínio, controles e continuidade difíceis de reconstruir. Eu procuraria a vantagem competitiva na qualidade dessa combinação, não na quantidade de funcionalidades anunciadas.
Há, ainda, uma disputa sobre quem escolhe a composição do processo. Uma camada que interpreta a demanda e encaminha tarefas pode influenciar quais serviços serão utilizados. Quem opera as capacidades pode procurar preservar distribuição, conhecimento e relacionamento. Isso permite cooperação e competição simultâneas. Para a empresa compradora, o risco é acreditar que eliminou uma dependência quando apenas a transferiu do aplicativo para o ambiente que coordena os demais.
Por essa razão, eu avaliaria a possibilidade de substituir componentes antes de tornar a operação dependente deles. Regras de aprovação, contexto organizacional, registros de execução e testes de qualidade precisam ter responsáveis e condições de continuidade compreendidas pela empresa. Não proponho independência absoluta, que pode ser cara e impraticável. Proponho saber qual liberdade foi preservada, qual foi cedida e quanto custaria recuperá-la.
Desmontar o produto não elimina o trabalho de coordená-lo
Uma arquitetura composta pode oferecer flexibilidade, mas alguém precisa responder pela experiência completa. Se o modelo interpretou corretamente, a API respondeu dentro do prazo e o sistema registrou a alteração, ainda assim o objetivo do cliente pode não ter sido atendido. O sucesso local de cada componente não assegura o sucesso do processo. Esse é o ponto em que a discussão precisa sair da gestão de fornecedores e chegar ao desenho de responsabilidade operacional.
Minha hipótese é que veremos dois movimentos convivendo: a decomposição de aplicações em capacidades mais acessíveis e a formação de novas ofertas que voltem a reunir essas capacidades, agora em torno de tarefas completas. Algumas empresas preferirão coordenar a composição; outras pagarão para reduzir esse esforço. Não interpreto essa possível recomposição como retorno ao ponto de partida. O objeto comprado pode mudar de uma ferramenta para uso humano para uma capacidade de execução com limites e critérios verificáveis.
Para o C-level, a decisão não deveria ser “comprar SaaS ou construir com IA”, mas onde faz sentido desenvolver diferenciação e onde compensa contratar uma operação especializada. Eu preservaria atenção interna sobre o que define a vantagem do negócio e compararia alternativas pelo ciclo completo, incluindo transição e saída. Produzir mais software não é, por si só, uma competência estratégica; saber o que merece existir, quem deve operá-lo e como avaliar sua contribuição pode ser.
Voltando à reunião de orçamento, eu não descartaria o protótipo nem aprovaria a troca do sistema pelo impacto da demonstração. Pediria que fosse comparado à operação real: como lida com exceções, o que acontece quando falha, quanto custa concluir o trabalho e quem responde pela continuidade. É nessa comparação que a transformação do SaaS se torna uma decisão empresarial, em vez de uma disputa de narrativas. O software poderá mudar de forma, de fornecedor e de remuneração; o que continuará precisando de uma resposta é a capacidade da empresa de operar melhor com ele.
Fontes consultadas
[1] Reuters Breakingviews. Software’s AI trade moves from fear to opportunity. 1 set. 2026.
[2] Anthropic. Anthropic and Salesforce expand partnership to bring Claude to regulated industries. 14 out. 2025.
[3] Salesforce. Salesforce and Anthropic Announce Claudeforce. 26 ago. 2026.
[4] Salesforce Help. Understand the Salesforce Headless360 Architecture. 29 jul. 2026.
[5] Salesforce. Agentforce Pricing. Consulta em 7 set. 2026.
[6] Salesforce. Salesforce Delivers Record Second Quarter Fiscal 2027 Results. 26 ago. 2026; trimestre encerrado em 31 jul. 2026.
