IA em produção para devs: como entregar ROI que o CFO entende

Li a pesquisa da Grant Thornton divulgada pelo Terra.com.br e fiquei pensando no que ela significa de verdade para quem está no código. 67% dos CFOs querem aumentar investimento em tecnologia e IA mesmo com pessimismo econômico no maior nível em 20 trimestres. Para o board, isso é estratégia corporativa. Para nós, devs, é sinal claro de onde o orçamento vai parar nos próximos 12 meses — e onde o nosso trabalho vai ser exigido.

O CFO virou protagonista da estratégia de IA

O dado mais importante da pesquisa não é o otimismo econômico (que caiu para 37%). É a frase do sócio da Grant Thornton: “A área financeira tornou-se protagonista na definição da estratégia empresarial.” Traduzindo para a nossa linguagem: quem decide o budget de IA agora fala a língua de ROI, não a língua de hype.

Na minha experiência, isso muda três coisas no dia a dia de quem programa:

• Feature com IA que não tem métrica de retorno associada vai ser cortada no próximo ciclo de planejamento.
• Stack de IA que não tem governança clara (logs, custos, fallback) vai virar problema de compliance.
• Experimentação solta sem alinhamento com KPIs financeiros vai perder funding para times que mostram números.

Se você está entrando em projetos de IA agora, ignore os benchmarks de Twitter. Foque em construir coisas que o CFO consegue colocar numa planilha.

IA deixou de ser aposta: virou decisão financeira

A pesquisa aponta que o desafio migrou de “como adotar IA” para “como medir retorno, governar e direcionar investimento”. Esse é exatamente o ponto onde 90% dos projetos de IA que eu vi nascerem em produção morreram. Não por falta de tecnologia — por falta de métrica.

Veja o que mudou no ciclo de decisão:

• 2023-2024: “Vamos usar LLM porque todo mundo está usando.” Board aprova, ninguém mede.
• 2025-2026: “Quanto custa por chamada? Qual a taxa de aceitação da saída? Quanto trabalho humano ainda é necessário para validar?” Board corta o que não responde essas perguntas.

Isso é bom. Mata os projetos de demo que só serviam para encher slide. Sobrem os que entregam valor real.

O que isso significa na prática para devs

Quando eu penso em IA aplicada hoje, separo em três camadas que precisam conversar com a área financeira:

1. Camada de custo: Cada chamada de LLM tem custo em tokens, latência e infraestrutura. Se você não instrumenta isso, está no escuro.
2. Camada de qualidade: Taxa de alucinação, taxa de aceitação pelo usuário, feedback estruturado. Sem isso, não tem como melhorar.
3. Camada de negócio: Quanto tempo economizado? Quantos tickets resolvidos sem intervenção humana? Quanto de receita incremental?

O dev que domina as três camadas vira peça-chave. O dev que só sabe fazer prompt vira commodity substituível por outro prompt engineer.

Na Prática: instrumentando custo de IA desde o dia 1

Vou mostrar um padrão que aplico em todo projeto de IA em produção: um decorator que rastreia custo, latência e metadata de cada chamada. É o tipo de coisa que faz o CFO dormir tranquilo.

import time
import functools
import json
from datetime import datetime
from dataclasses import dataclass, asdict

@dataclass
class AIUsageRecord:
    timestamp: str
    function: str
    model: str
    input_tokens: int
    output_tokens: int
    cost_usd: float
    latency_ms: int
    user_id: str
    success: bool

# Pricing por 1k tokens (exemplo GPT-4o, atualize conforme o modelo)
PRICING = {
    "gpt-4o": {"input": 0.0025, "output": 0.01},
    "gpt-4o-mini": {"input": 0.00015, "output": 0.0006},
    "claude-sonnet-4": {"input": 0.003, "output": 0.015},
}

def track_ai_usage(model: str):
    def decorator(func):
        @functools.wraps(func)
        def wrapper(*args, **kwargs):
            start = time.perf_counter()
            user_id = kwargs.pop("_user_id", "anonymous")
            try:
                result = func(*args, **kwargs)
                latency = int((time.perf_counter() - start) * 1000)

                input_tokens = result.get("usage", {}).get("prompt_tokens", 0)
                output_tokens = result.get("usage", {}).get("completion_tokens", 0)

                price = PRICING.get(model, {"input": 0, "output": 0})
                cost = (input_tokens / 1000) * price["input"] + \
                       (output_tokens / 1000) * price["output"]

                record = AIUsageRecord(
                    timestamp=datetime.utcnow().isoformat(),
                    function=func.__name__,
                    model=model,
                    input_tokens=input_tokens,
                    output_tokens=output_tokens,
                    cost_usd=round(cost, 6),
                    latency_ms=latency,
                    user_id=user_id,
                    success=True,
                )
                _send_to_analytics(asdict(record))
                return result
            except Exception as e:
                _send_to_analytics({"error": str(e), "function": func.__name__})
                raise
        return wrapper
    return decorator

def _send_to_analytics(record: dict):
    # Em produção: envie para Datadog, Amplitude, BigQuery, etc.
    print(json.dumps(record))

# Exemplo de uso:
@track_ai_usage(model="gpt-4o-mini")
def summarize_ticket(ticket_text: str, _user_id: str = "agent-42"):
    from openai import OpenAI
    client = OpenAI()
    response = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": f"Resuma: {ticket_text}"}],
    )
    return {
        "content": response.choices[0].message.content,
        "usage": response.usage.model_dump(),
    }

Com isso você responde em segundos perguntas como: “Quanto estamos gastando por usuário?”, “Qual feature está custando mais do que gera?”, “Esse modelo é melhor ou só mais barato?”. É a diferença entre dev que implementa IA e dev que entrega IA com accountability.

Comparando as opções reais de stack de IA

Muita gente me pergunta qual stack usar. Não existe resposta única, mas existe trade-off claro. Vou colocar o que costumo avaliar:

Minha regra pessoal: comece com API para validar hipótese. Quando o custo mensal passar de 4 dígitos, avalie modelo próprio. Quando passar de 5 dígitos, fine-tune ou destile.

Erros comuns que eu vejo em projetos de IA

Depois de revisar dezenas de projetos, esses são os erros que mais matam iniciativa de IA antes de gerar retorno:

1. Tratar LLM como caixa-preta mágica

Se você não consegue explicar por que o modelo deu aquela resposta, não consegue auditar, corrigir ou melhorar. Sempre versione prompts, salve outputs, tenha dataset de avaliação. Sem isso, cada mudança é um tiro no escuro.

2. Ignorar o custo de validação humana

IA que precisa de revisão humana em 80% dos casos não está economizando — está adicionando uma camada de retrabalho. Meça o tempo humano gasto em pós-edição. Muitas vezes, automatizar sem IA sai mais barato.

3. Não ter fallback determinístico

LLM falha. Alucina. Fica fora do ar. Se sua aplicação trava quando o modelo falha, você está com problema sério de arquitetura. Sempre tenha um caminho alternativo: busca clássica, resposta em cache, escalonamento para humano.

4. Otimizar latência antes de otimizar relevância

Eu vejo times gastando semanas para reduzir 200ms de latência enquanto o modelo dá 30% de respostas irrelevantes. Relevância importa 10x mais que velocidade na maioria dos casos. Comece pela qualidade da saída, depois otimize a infraestrutura.

5. Vendor lock-in disfarçado de “stack moderna”

Acoplar toda sua lógica de negócio ao schema de um vendor específico é pedir para ser refém. Use uma camada de abstração (interface própria + adapter). Trocar de provedor deve levar dias, não meses.

# Camada de abstração - exemplo de contrato
from abc import ABC, abstractmethod
from typing import Protocol

class TextGenerator(Protocol):
    def generate(self, prompt: str, **kwargs) -> str: ...

class OpenAIAdapter:
    def __init__(self, client): self.client = client
    def generate(self, prompt: str, **kwargs) -> str:
        r = self.client.chat.completions.create(
            model=kwargs.get("model", "gpt-4o-mini"),
            messages=[{"role": "user", "content": prompt}],
        )
        return r.choices[0].message.content

class LocalOllamaAdapter:
    def __init__(self, base_url="http://localhost:11434"): self.url = base_url
    def generate(self, prompt: str, **kwargs) -> str:
        import requests
        r = requests.post(f"{self.url}/api/generate",
                          json={"model": kwargs.get("model", "llama3"),
                                "prompt": prompt, "stream": False})
        return r.json()["response"]

# Trocar de provedor = mudar uma linha
generator: TextGenerator = OpenAIAdapter(openai_client)
# generator: TextGenerator = LocalOllamaAdapter()

Implicações para sua carreira como dev

A pesquisa diz que 67% dos CFOs vão aumentar investimento em tech. Isso não significa que vão contratar mais devs. Significa que vão direcionar budget para quem entrega com métrica. O que eu faria se estivesse começando agora:

• Aprenda a falar ROI. Não só “implementei feature X”. Mas “feature X reduziu tempo de Y em Z%, economizando R$ W por mês”.
• Domine pelo menos uma camada de IA generativa com profundidade. Não só prompt. Mas embeddings, RAG, fine-tuning, avaliação.
• Entenda o básico de FinOps para IA. Cost optimization em cloud já é skill valorizada. Aplicado a IA, é ainda mais raro.
• Construa um projeto open-source sério. É o único portfólio que sobrevive à filtragem automatizada de currículos.

FAQ — Perguntas reais que devs fazem sobre IA em produção

Como calcular o custo real de uma feature de IA?

Some custo de tokens + custo de infra (vector DB, embedding, hospedagem) + custo humano de validação. Divida pelo número de usuários ou chamadas úteis. Compare com o custo da alternativa sem IA. Se não for menor, refaça a hipótese.

Vale a pena fine-tunar um modelo ou só usar prompt engineering?

Na maioria dos casos, prompt engineering + RAG resolve. Fine-tuning vale quando você tem volume alto (>100k chamadas/mês), tarefa específica repetitiva e dados rotulados suficientes (>10k exemplos). Antes disso, é otimização prematura.

Como evitar alucinações sem virar refém de validação humana?

Técnicas que funcionam em produção: restringir o contexto (RAG com fontes citadas), usar structured outputs (JSON schema forçado), implementar guardrails com modelo menor classificando a saída, e ter circuit breaker quando a confiança fica baixa.

Open-source (LLaMA, Mistral, Qwen) ou API paga?

Depende do tripé custo-volume-compliance. Open-source vence em dados sensíveis e alto volume. API paga vence em MVPs e tarefas que precisam do estado da arte. Em 2026, a diferença de qualidade entre top open-source e API caiu drasticamente — não subestime modelos como Qwen e DeepSeek.

Como mostrar valor de IA para um CFO que não entende tecnologia?

Uma métrica, uma frase, um número. Exemplo: “Reduzimos o tempo médio de resposta ao cliente de 4h para 12 minutos, diminuindo R$ 18k/mês em custo operacional.” Sem tecnicismo. Sem jargão. Só o impacto no P&L.

O que eu levo da pesquisa da Grant Thornton

O CFO não está mais perguntando “devemos investir em IA?”. Está perguntando “qual projeto de IA paga o investimento?”. Para nós, devs, isso é libertador: mata os projetos de teatro, sobra budget para o que funciona, e valoriza quem entrega com disciplina.

O profissional que combina profundidade técnica com mentalidade de produto e clareza financeira vai estar nos 10% mais disputados do mercado nos próximos anos. Não porque IA é hype — porque IA virou linha da planilha.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.