Do Software como Serviço ao Serviço como Software: a evolução que o mercado global está validando agora, e que a gestão pública brasileira já pratica

A AWS acaba de anunciar um investimento de US$ 1 bilhão para criar uma unidade própria de engenheiros embutidos dentro da operação de seus clientes, com a missão de transformar meses de implantação de inteligência artificial em dias. Antes dela, a OpenAI e a Anthropic já haviam formalizado suas próprias empresas de implantação, seguindo um modelo que a Palantir criou há mais de duas décadas. Databricks, ServiceNow e Salesforce correm atrás do mesmo território.

O nome técnico que o mercado deu a esse movimento é Forward Deployed Engineering. O nome estratégico é mais simples e mais importante: é a virada do Software como Serviço para o Serviço como Software.

A diferença entre vender uma ferramenta e entregar um resultado

O modelo de Software como Serviço, o SaaS que dominou a última década, tem uma lógica clara: o fornecedor entrega uma plataforma, o cliente assina, e a responsabilidade de operar, adotar e extrair resultado da ferramenta fica inteiramente do lado de quem contratou. Funciona bem para processos padronizados. Funciona mal para problemas complexos, onde a variável decisiva não é a existência do software, é a capacidade de aplicá-lo corretamente dentro de uma operação real, com dados reais, prazos reais e risco político real.

O Serviço como Software inverte essa lógica. O software deixa de ser o produto final e passa a ser o motor de execução dentro de um serviço contínuo, com equipe, metodologia e responsabilidade de resultado do lado de quem entrega. A remuneração deixa de estar atrelada a licença de uso e passa a estar atrelada ao desfecho.

É exatamente esse modelo que a AWS está pagando um bilhão de dólares para provar em escala corporativa global, embutindo equipes de cinco a seis engenheiros por até 45 dias dentro de clientes como NBA, NFL, Southwest Airlines e Cox Automotive.

A gestão pública brasileira já opera essa lógica

A Ana Smart Solutions já opera essa lógica na gestão pública brasileira.

A arquitetura da empresa não foi desenhada como três produtos separados. É uma única estrutura de entrega em três camadas: o DIRECITY GOV como motor de execução, o suporte especializado em estruturação de investimento MIP/PPP como camada de enquadramento técnico e financeiro, e as palestras e a presença institucional como canal de relação contínua e suporte com o gestor público. O software executa. O suporte especializado estrutura o caso de negócio. A presença institucional sustenta a confiança ao longo do tempo.

Isso é Serviço como Software aplicado à realidade fiscal municipal, antes mesmo de o mercado global nomear o modelo.

Os módulos técnicos que sustentam essa entrega cobrem o ciclo completo da gestão pública, do planejamento à correção de rumo: análise de procurement do PNCP, painel declarado versus auditado do Raio X Financeiro, monitoramento de índices constitucionais fiscais, Plano Diretor de Tecnologia e Cidade Inteligente, gestão de projetos e riscos, análise de viabilidade financeira, banco de soluções e projetos validados, gestão e correção do IEGM, alinhamento com os Objetivos de Desenvolvimento Sustentável e com as normas ISO 37120, 37122 e 37123.

Nenhum desses módulos é vendido isoladamente como funcionalidade de uma plataforma. Cada um é uma entrega dentro de um serviço contínuo que usa o software como instrumento de garantia de resultado.

A eficiência automatizada dentro do método, não no formato de remuneração

Existe uma diferença estrutural entre o que a AWS está construindo agora e o que a gestão pública brasileira já pode contratar hoje, e ela não está na forma de pagamento, está no lugar onde a eficiência mora.

A Lei 14.133/2021 prevê o contrato de eficiência, com remuneração vinculada a percentual da economia comprovada, um instrumento jurídico legítimo e disponível para quem quiser estruturar dessa forma. O DIRECITY GOV não segue esse caminho. A plataforma é contratada por assinatura, conforme o porte populacional do município, sem vincular a remuneração a percentual de economia gerada.

A diferença é que a eficiência não depende do formato do contrato, ela está automatizada dentro do próprio método. A plataforma desenha projetos que trazem resultados comprovados e eficiência para a gestão pública como parte do seu funcionamento padrão, não como cláusula de um contrato específico. O resultado não é uma promessa condicionada a um modelo de remuneração, é consequência direta da metodologia embutida na ferramenta, do jeito que Pindamonhangaba já demonstrou, com R$ 210 milhões em economia, crescimento de receita de R$ 380 milhões para R$ 1 bilhão, anos consecutivos de avaliações Grau A no IEGM i-GOV TI e tripla certificação ISO com nota máxima na primeira avaliação.

Isso resolve, de forma mais sólida, a objeção mais comum de um secretário de fazenda diante de uma nova tecnologia: por que pagar antes de ver resultado. A resposta não depende de negociar uma cláusula de remuneração por desempenho, depende de mostrar que o método que gera o resultado já está validado e automatizado dentro da plataforma que está sendo contratada.

Parceria, não disputa

Nada disso posiciona a Ana Smart Solutions como concorrente da AWS ou das demais big techs que estão investindo nesse território. A infraestrutura de nuvem e os modelos de inteligência artificial de ponta são a camada correta para vir de um hyperscaler global. A camada de domínio, o contexto jurídico brasileiro, a metodologia de gestão pública e a responsabilidade pelo resultado são a camada correta para vir de quem construiu e validou essa metodologia dentro da realidade fiscal e institucional dos municípios brasileiros.

O mercado global está gastando bilhões de dólares para provar um modelo de entrega que a gestão pública brasileira já pratica, com enquadramento jurídico nacional, dado sob jurisdição brasileira e resultado auditado. A conversa que resta não é sobre adotar essa tendência. É sobre estruturar, com quem já sabe fazer isso, o contrato certo para o seu município.