Saltar para o conteúdo
SwankyForge
SwankyForge
Todos os artigos
Artigo12 min de leitura

Quando a IA reduz as horas, um preço fixo por marco com tarifas publicadas reparte a poupança em vez de a esconder

A faturação à hora entrega ao cliente cada hora poupada, um preço fixo opaco entrega-a ao fornecedor; um exemplo calculado mostra um meio-termo que ambas as partes podem verificar.

Os assistentes de programação com IA tornaram partes do trabalho de engenharia mais baratas de produzir. Os compradores sabem-no e estão a pedir a poupança. Esta nota é sobre quem fica com ela, e porque é que a resposta depende menos da ferramenta do que da forma como o trabalho é orçamentado.

A versão curta, se está a comprar

Há três formas comuns de orçamentar o mesmo trabalho.

  • À hora. Paga cada hora trabalhada. Se as ferramentas de IA reduzirem as horas, paga menos. Também assume o risco de derrapagem, e o fornecedor ganha menos por se ter tornado mais rápido, por isso o modelo de preço não lhe dá nenhuma razão para ficar mais rápido.
  • Preço fixo, sem discriminação. Conhece o preço à partida. Se o trabalho ficou mais barato de produzir, não o vê. O fornecedor fica com toda a poupança até alguém renegociar.
  • Tarifas publicadas, preço fixo por marco. O fornecedor mostra as horas por função às tarifas publicadas, fixa o preço de cada marco e só fatura depois de o aceitar face a uma métrica acordada antes de o trabalho começar. Paga menos do que antes e conhece o valor antecipadamente. O fornecedor mantém a margem sobre a eficiência que realmente obtém, e assume o risco se não a obtiver.

O terceiro é o modelo que oferecemos: tarifas na página de preços, uma calculadora que multiplica as horas por função por essas tarifas, um preço fixado assim que o âmbito é acordado e uma fatura por marco após a aceitação. O exemplo calculado abaixo mostra a aritmética com números ilustrativos.

O que está a fazer o mercado

A pressão é explícita, e está a chegar aos contratos antes de chegarem à renovação.

  • Os clientes querem a poupança já. Em agosto de 2026, a Reuters noticiou que os clientes das grandes empresas de serviços de TI exigiam «the same work for 25% to 30% less», nas palavras do presidente executivo da Persistent Systems. A TCS disse que cerca de 80% dos contratos no seu segmento de serviços financeiros, de RH e de negócio se baseiam agora em medidas de resultado, o que uma pessoa conhecedora do assunto descreveu como o dobro da proporção no final de 2023. A mesma notícia descreve um contrato de automação da Cognizant que reparte entre fornecedor e cliente as poupanças de custos relacionadas com IA, segundo pessoas conhecedoras dos seus termos.
  • A renegociação não espera pela renovação. Uma notícia de junho de 2026 republicada pela HFS Research descreve clientes a reabrir contratos no prazo de 24 meses para captar eficiências da IA, com os contratos acima de 50 milhões de dólares por ano sob maior pressão. O presidente executivo da HFS descreveu a conversa como a afastar-se de FTEs e tabelas de tarifas em direção a compromissos de produtividade, preços baseados em resultados e partilha de ganhos.
  • As margens, em geral, mantiveram-se até agora. A UpperEdge analisou os resultados do 2.º trimestre de 2026 de onze grandes fornecedores. Vários alargaram as margens operacionais: a Wipro em 80 pontos base para 17,3%, a Tech Mahindra em 60 para 11,1%, a Accenture em 20 para 17,0%. A margem da TCS comprimiu para 24,0%, o que a UpperEdge atribui a aumentos salariais e a investimento em infraestrutura de IA, e a margem EBITDA ajustada da Kyndryl caiu de 17,3% para 14,2%. A leitura da UpperEdge é que o investimento em IA está, até agora, «funding itself rather than generating new client spend». Nota também que a TCS diz agora que uma melhoria de 10–15% impulsionada pela IA pode ser comprometida desde o primeiro dia de um contrato, contra os tradicionais 3–5% distribuídos ao longo da vida do contrato.
  • A direção está definida. A IDC espera que 30% de todos os contratos com prestadores de serviços sejam baseados em resultados até 2029.

Os grandes contratos de outsourcing não são o mercado de um laboratório de dois engenheiros. Mas a mecânica é a mesma a 15.000 dólares e a 50 milhões. Alguém decide quem fica com a poupança, e o contrato ou mostra essa decisão ou esconde-a.

Qual é a dimensão da poupança? Menor e mais incerta do que os títulos

Programar é uma fração do trabalho. O Technology Report de 2025 da Bain concluiu que as equipas que usam assistentes de programação com IA registam ganhos de produtividade de 10–15%. Ganhos de 25–30% só aparecem quando a IA vem com um redesenho de todo o processo. Escrever e testar código ocupa cerca de 25–35% do tempo entre a ideia e o lançamento, por isso até um grande ganho de velocidade na escrita de código move muito menos o total.

Medir é difícil. O ensaio aleatorizado de 2025 do METR concluiu que programadores open-source experientes demoraram mais 19% com ferramentas de IA. Em fevereiro de 2026, reportou que os dados do estudo de seguimento mostravam «some evidence for speedup» e que os programadores eram provavelmente mais rápidos no início de 2026 do que no início de 2025. Classificou também esses dados como evidência muito fraca sobre a dimensão da mudança, porque cada vez mais programadores recusavam trabalhar sem IA e assim saíam da comparação. Os seus dois novos intervalos de confiança continuam a incluir a ausência de efeito.

Prometer uma poupança antecipadamente é uma aposta. Na mesma notícia da Reuters, o presidente executivo da Tech Mahindra disse que alguns concorrentes estavam a incluir no preço ganhos de produtividade de 70–80% ao longo de cinco a sete anos e a garantir preços nessa base, e que a sua empresa tinha optado por não correr esse risco.

Também não medimos a nossa própria poupança. Um contrato que promete um desconto percentual fixo por IA promete algo que ninguém ainda consegue verificar. Um contrato que fixa o preço de um marco e deixa o risco da estimativa com o fornecedor não precisa desse número.

Um exemplo calculado (ilustrativo)

Tudo nesta secção é ilustrativo. As horas poupadas são um pressuposto, não uma medição. Os valores de custo são marcadores de posição, não a nossa estrutura de custos.

Referência. Tome o modelo de copiloto RAG da nossa calculadora: 310 horas em cinco funções, 14.500 € às tarifas publicadas e com complexidade padrão. Trate-o como a estimativa sem assistência de IA. Depois assuma que a assistência de IA reduz as horas gastas em código repetitivo, testes e documentação, função a função:

Função Tarifa (USD/h) Horas antes Horas depois (assumidas) Para onde vão as horas
Engenheiro de ML 50 120 108 (−10%) harness de avaliação e loaders; o desenho da avaliação não muda
Engenheiro de dados 45 60 52 (−13%) estrutura de ingestão, testes de dados
Engenheiro de backend 40 60 45 (−25%) estrutura da API, testes de integração
Engenheiro de MLOps 55 40 32 (−20%) configuração de CI, dashboards, runbooks
Gestor de produto 40 30 30 (0%) métrica, âmbito, conversas com o cliente
Total 310 h = 14.500 € 267 h = 12.500 € −43 h, −13,9%

Escolhemos 13,9% porque fica dentro do intervalo de 10–15% da Bain para os assistentes por si só.

Mais dois marcadores de posição. Uma hora de entrega custa ao fornecedor 60% da tarifa faturada, e as ferramentas de IA custam 300 € ao longo do marco.

Quatro formas de orçamentar:

Modelo de preço O cliente paga Custo do fornecedor Margem do fornecedor Margem por hora trabalhada
A. À hora, antes da IA (310 h trabalhadas) 14.500 € 8.700 € 5.800 € (40,0%) 18,71 €
B. À hora, depois da IA (267 h) 12.500 € 7.800 € 4.700 € (37,6%) 17,60 €
C. Fixo ao preço antigo, depois da IA (267 h) 14.500 € 7.800 € 6.700 € (46,2%) 25,09 €
D. Marco fixo orçamentado a 288 h, entregue em 267 h 13.480 € 7.800 € 5.680 € (42,1%) 21,27 €

A aritmética. O custo em A é 60% × 14.500 €. Em B, C e D é 60% × 12.500 € + 300 €. A margem por hora trabalhada é a margem dividida pelas horas efetivamente trabalhadas: 310 em A, 267 nas restantes. Em D, o fornecedor compromete-se com uma estimativa que conta metade da poupança esperada em cada função: ML 114 h, dados 56, backend 52, MLOps 36, PM 30. São 288 horas, e 13.480 € às tarifas publicadas. (A calculadora arredonda cada função à centena de dólares mais próxima, por isso mostraria 13.500 €.)

O que a tabela diz:

  • B é o que a faturação à hora faz a um fornecedor que fica mais rápido. O cliente poupa 2.000 €. A margem do fornecedor cai 1.100 €, e a sua margem por hora trabalhada desce 6% abaixo do que era antes da IA. Só a recupera se conseguir vender as 43 horas libertadas a outra pessoa. Uma empresa grande com uma fila de trabalho consegue. Um laboratório de dois engenheiros com um ou dois projetos em simultâneo muitas vezes não consegue. Em qualquer dos casos, o modelo de preço recompensa trabalhar mais devagar.
  • C é o que faz um preço fixo opaco. O fornecedor fica com toda a poupança e ganha mais 34% por hora trabalhada do que em A. O cliente não consegue ver isto. Quando descobre, o resultado é a renegociação a meio do contrato que as notícias acima descrevem.
  • D reparte a poupança às claras. O cliente paga menos 1.020 € (7,0%) do que antes da IA, conhece o valor antes de o trabalho começar e só paga depois de aceitar o marco. O fornecedor ganha cerca de mais 14% por hora trabalhada do que em A. Ambas as partes conseguem ver como o preço foi construído: horas por função, vezes as tarifas publicadas.

D também tem um lado negativo, e pertence ao fornecedor. Se a poupança não aparecer e o trabalho levar as 310 horas completas, o custo é 9.000 € (60% × 14.500 € + 300 €) e a margem cai para 4.480 € (33,2%). O cliente continua a pagar 13.480 €. Assumir esse risco é o que dá ao fornecedor direito ao ganho.

Comparado com B, o cliente em D paga mais 980 € no papel. Em troca, obtém um valor fixo em vez de um taxímetro aberto, e paga só depois da aceitação. Se isso vale 980 € depende de quanto confia na estimativa. É por isso que as horas são publicadas.

Porque é que a métrica e o passo de aceitação importam

Um preço fixo sem uma definição de concluído apenas empurra a discussão para o fim do projeto. Há duas coisas que fazem a opção D funcionar.

A métrica é acordada antes do treino e escrita no contrato. Para um copiloto RAG, por exemplo, pode ser a fração de respostas consideradas corretas num conjunto de perguntas acordado, mais um limite de tempo de resposta.

A aceitação vem antes da fatura. Verifica o marco face à métrica antes de pagar. Se o código escrito pela IA cortou caminho, isso aparece na aceitação, não depois do pagamento final.

Isto é mais restrito do que os preços baseados em resultados no sentido em que a IDC e a TCS usam o termo, que liga os honorários a resultados de negócio. Em sistemas de ML, um resultado de negócio como a receita depende também de preços, stock, marketing e sazonalidade, nada disso controlado pelo fornecedor. Uma métrica de sistema que ambas as partes conseguem medir na aceitação é aquilo por que um fornecedor pode honestamente ser responsabilizado. O resultado de negócio é medido depois, num teste A/B.

Onde isto não funciona

Risco de investigação. Se ninguém sabe se os dados conseguem sustentar o modelo, um preço fixo é uma aposta para ambas as partes. Faça primeiro uma descoberta paga; o teardown gratuito diz-lhe se precisa de uma. A nossa leva 2–3 semanas e custa 6k–14k €.

Âmbito que muda todas as semanas. Um marco fixo precisa de um âmbito congelado para esse marco. Se isso for impossível, a faturação à hora com um teto é mais honesta.

Poupanças que nunca chegam ao orçamento seguinte. Em D, o fornecedor fica com a margem extra neste marco. No orçamento seguinte, as horas por função devem refletir o que aprendeu. Se não descerem, pergunte porquê. É essa verificação que impede D de derivar para C.

O que perguntar a um fornecedor sobre poupanças com IA

  1. Que partes deste trabalho vão ter assistência de IA, e o que assume que isso faz às horas, função a função?
  2. Esse pressuposto está no preço que apresentou? Mostre as horas e as tarifas.
  3. Quem paga se a estimativa estiver errada, em qualquer dos sentidos?
  4. O que aceitamos antes de cada fatura, e face a que métrica?
  5. Mediu o seu próprio ganho de velocidade? Como, e em que janela? Uma autoavaliação não é uma medição: os participantes do METR acreditavam ser 20% mais rápidos quando eram 19% mais lentos.
  6. Quem revê o código escrito pela IA, e que verificações correm em cada alteração?
  7. Que ferramentas de IA vão ver o nosso código e os nossos dados, e em que condições?
  8. O próximo orçamento vai refletir o que aprendeu neste?

Um fornecedor que responde depressa a estas perguntas já fez as contas. As nossas começam na calculadora da página de preços, que mostra as horas e as tarifas por função para o seu projeto.

Fontes

Tem um processo que custa demasiado?

Fale-nos dele. A primeira chamada é gratuita e, se a IA não for a resposta, dizemo-lo.

Falar sobre a sua tarefa