A velocidade da IA não é o principal problema para quem desenvolve software. O desafio é decidir onde ela cria valor suficiente para justificar custo, risco e manutenção. Se eu adiciono um modelo a um fluxo sem medir qualidade, latência e impacto no trabalho da equipe, não estou modernizando o produto: estou acrescentando uma dependência cara e difícil de controlar.
A segunda Lisbon AI Week ajuda a colocar essa discussão no contexto certo. Segundo o Observador.pt, entre 21 e 27 de setembro, cerca de cinquenta eventos reuniram aproximadamente 2.500 participantes em Lisboa. Em comparação com a edição anterior, a conversa avançou da pergunta “o que a IA consegue fazer?” para uma mais útil: “o que acontece quando a colocamos em produção?”.
Lisbon AI Week: da demonstração de IA à aplicação em produção
O Observador.pt relata que a IA foi discutida em áreas como jornalismo, saúde, recrutamento, sustentabilidade, marketing, arte e defesa. Para desenvolvedores, a diversidade importa porque não existe uma implementação universal. Um assistente de escrita, um sistema de triagem de currículos e uma ferramenta de apoio clínico têm requisitos diferentes de precisão, privacidade e supervisão.
Uma demonstração pode parecer impressionante e ainda falhar como produto. Em produção, precisamos responder a perguntas menos vistosas: como detectar uma resposta errada? Quanto custa cada solicitação? O que acontece quando o fornecedor fica indisponível? Que dados podem sair do nosso ambiente? E quem revisa o resultado antes que ele afete uma pessoa?
Essa mudança de foco é o sinal mais relevante da semana. Integrar um modelo ficou relativamente simples. Construir um sistema confiável ao redor dele continua exigindo engenharia convencional: observabilidade, testes, controle de acesso, tratamento de erros e decisões claras sobre responsabilidade.
O custo da inteligência artificial não é apenas o preço por token
Na conversa citada pelo Observador.pt, Pedro Morais Leitão antecipou uma escalada de custos, enquanto Rudolf Gruner lembrou a dimensão dos investimentos feitos por empresas de tecnologia e resumiu o problema: “Alguém vai ter que pagar isto”. Para quem desenvolve, isso não é apenas uma questão macroeconômica. É uma decisão diária de arquitetura e orçamento.
O custo direto de uma API costuma ser calculado a partir dos tokens de entrada e de saída. Mas o custo real também inclui tentativas repetidas, chamadas a ferramentas, armazenamento de documentos, embeddings, avaliação, monitoramento e revisão humana. Um fluxo que parece barato num teste manual pode ficar caro quando recebe milhares de solicitações, ou quando um prompt longo é enviado sem necessidade em cada chamada.
Eu começaria medindo o custo por tarefa concluída, não apenas o custo por chamada. Se um sistema custa pouco por resposta, mas erra com frequência e exige que uma pessoa refaça o trabalho, a economia é ilusória. A métrica útil combina custo, tempo poupado e qualidade, comparando o processo com a alternativa existente.
Como estimar o custo de inferência antes de publicar
O exemplo abaixo calcula o custo estimado de uma chamada com base nos tokens e nos preços informados por milhão de tokens. Os valores são argumentos, não constantes: os preços variam entre modelos e fornecedores e podem mudar. O cálculo também não inclui armazenamento, ferramentas ou impostos.
from decimal import Decimal, InvalidOperation
import argparse
def positive_int(value: str) -> int:
number = int(value)
if number < 0:
raise argparse.ArgumentTypeError("O valor não pode ser negativo.")
return number
def non_negative_decimal(value: str) -> Decimal:
try:
number = Decimal(value)
except InvalidOperation as exc:
raise argparse.ArgumentTypeError("Informe um número válido.") from exc
if number < 0:
raise argparse.ArgumentTypeError("O valor não pode ser negativo.")
return number
parser = argparse.ArgumentParser(
description="Estima o custo de uma chamada a um modelo de IA."
)
parser.add_argument("--input-tokens", type=positive_int, required=True)
parser.add_argument("--output-tokens", type=positive_int, required=True)
parser.add_argument("--input-price", type=non_negative_decimal, required=True,
help="Preço por milhão de tokens de entrada.")
parser.add_argument("--output-price", type=non_negative_decimal, required=True,
help="Preço por milhão de tokens de saída.")
args = parser.parse_args()
million = Decimal("1000000")
input_cost = Decimal(args.input_tokens) * args.input_price / million
output_cost = Decimal(args.output_tokens) * args.output_price / million
total = input_cost + output_cost
print(f"Entrada: ${input_cost:.8f}")
print(f"Saída: ${output_cost:.8f}")
print(f"Total: ${total:.8f}")Por exemplo, o comando python cost.py --input-tokens 1200 --output-tokens 300 --input-price 2 --output-price 8 estima o custo usando os preços passados no próprio comando. A separação entre entrada e saída é importante porque muitos modelos cobram tarifas diferentes para cada uma. Antes de comparar fornecedores, confirme também como eles tratam cache, chamadas em lote e tokens de raciocínio.
Automação e emprego: o que muda para quem está começando
O debate sobre trabalho também apareceu na semana. Segundo o Observador.pt, Pedro Morais Leitão apontou a dificuldade que profissionais com pouca experiência podem encontrar para agregar valor em tarefas que a IA já executa, enquanto profissionais mais experientes podem assumir maior responsabilidade pela validação dos resultados.
Na engenharia de software, isso não significa que todo trabalho júnior desaparece. Significa que parte das tarefas usadas para aprender — escrever testes simples, documentar funções, explorar uma API ou montar uma primeira versão — pode ser acelerada por ferramentas de IA. O risco é confundir velocidade de entrega com domínio técnico.
Um código gerado pode compilar e ainda conter uma falha de autorização, uma consulta vulnerável ou uma suposição errada sobre o domínio. Por isso, a competência que ganha valor não é apenas produzir mais linhas por hora. É formular requisitos, reconhecer quando a solução está errada, verificar comportamentos e explicar as consequências de uma decisão.
Para quem está começando, eu trataria a IA como um par de programação que precisa de supervisão, não como uma fonte de respostas finais. Peça uma implementação, mas também examine as dependências, escreva testes independentes e tente explicar o código sem consultar o modelo. Se não consegue fazer isso, a ferramenta acelerou a digitação, mas não o aprendizado.
Na Prática: integrar IA sem transformar o sistema numa caixa-preta
Para uma funcionalidade como resumir documentos internos, eu seguiria este processo antes de liberar o recurso para todos:
- Defina a tarefa e o limite. Especifique quem usa o resumo, quais documentos entram e o que o sistema não deve inferir. “Resumir” é vago; “listar decisões e pendências mencionadas no texto, sem inventar responsáveis” é verificável.
- Crie um conjunto de avaliação. Separe exemplos representativos, incluindo documentos curtos, longos, incompletos e com informação contraditória. Registre o resultado esperado e os critérios para considerar uma resposta aceitável.
- Compare com alternativas mais simples. Antes de usar um modelo generativo, teste regras, busca textual ou um modelo menor. Se a tarefa for encontrar uma expressão conhecida, uma consulta determinística costuma ser mais barata e previsível.
- Limite dados e permissões. Envie apenas o contexto necessário. Não coloque credenciais, dados pessoais ou conteúdo confidencial no prompt por conveniência. A política do fornecedor e a configuração de retenção precisam ser verificadas.
- Registre o que importa. Acompanhe latência, falhas, versão do modelo, custo estimado e resultados da avaliação. Evite gravar prompts sensíveis em logs abertos. Use identificadores e retenção controlada.
- Inclua revisão humana quando o erro tiver impacto. Um resumo interno pode ser apresentado como rascunho. Uma decisão sobre emprego, crédito ou saúde exige controles muito mais fortes e não deve ser tratada como simples autocomplete.
- Faça uma liberação gradual. Comece com um grupo pequeno, compare com o fluxo anterior e defina como desligar a funcionalidade. Um recurso de IA precisa ter fallback, não apenas um caminho feliz.
Eu também manteria a chamada ao modelo atrás de uma interface própria no backend. Assim, a aplicação não fica acoplada a um fornecedor específico, e podemos trocar o modelo, adicionar cache ou aplicar limites de uso sem espalhar lógica de IA por todo o frontend.
Erros comuns ao colocar modelos de IA em aplicações
- Escolher pelo resultado mais impressionante na demonstração. Uma resposta convincente não comprova precisão. Avalie exemplos reais e casos de falha, não apenas prompts preparados para a apresentação.
- Enviar contexto demais. Colocar documentos inteiros no prompt pode aumentar latência e custo, além de dificultar a identificação da informação relevante. Recuperação de trechos é uma alternativa, mas também precisa ser avaliada: busca ruim produz contexto ruim.
- Tratar a saída como dado confiável. Texto gerado não é validação de negócio. Se a resposta precisa obedecer a um esquema, valide o formato e os valores no servidor. Uma saída JSON bem formada ainda pode conter informação falsa.
- Ignorar injeção de prompt. Conteúdo recuperado de páginas, e-mails ou documentos pode incluir instruções maliciosas. Não dê ao modelo permissões que ele não precisa; ferramentas com efeitos externos devem exigir validação e autorização fora do modelo.
- Medir apenas a latência média. A cauda da distribuição importa. Acompanhe percentis, timeouts, limites de requisição e indisponibilidade do fornecedor. Defina respostas degradadas para que uma falha de IA não derrube toda a aplicação.
- Não comparar com o processo atual. Se uma tarefa manual leva dois minutos e o fluxo com IA leva um minuto, mas exige revisão adicional de três minutos, não houve ganho operacional.
Modelos generativos, regras e revisão humana: quando usar cada alternativa
Modelos generativos são úteis quando a entrada é variada e a tarefa envolve linguagem, como rascunhar uma resposta ou resumir conteúdo. Regras são melhores quando o comportamento precisa ser determinístico e a condição é conhecida. Busca tradicional funciona bem para localizar correspondências; busca semântica pode ajudar quando o usuário não conhece os termos exatos, mas não garante que o resultado encontrado seja verdadeiro ou relevante.
Na prática, sistemas robustos combinam essas abordagens. Eu usaria código convencional para autenticação, autorização, limites e validação. Deixaria o modelo fazer a parte probabilística e trataria sua resposta como uma sugestão sujeita a regras. Quando o impacto for alto, a revisão humana não é uma falha de automação; é parte do desenho do produto.
Também evitaria escolher um modelo maior por padrão. Começaria pelo menor que atenda aos critérios de qualidade e escalaria apenas quando os testes mostrarem uma diferença útil. Isso reduz custo e latência, mas a decisão precisa vir de avaliação, não de suposição. Um modelo mais barato que falha nos casos importantes pode sair mais caro no fluxo completo.
FAQ sobre IA para desenvolvedores
Como saber se um recurso de IA vale o custo?
Compare o custo total com o processo atual: chamadas, infraestrutura, revisão, erros e manutenção. Meça também qualidade e tempo por tarefa concluída. Se a IA reduz o tempo de geração, mas aumenta o retrabalho, o benefício pode não existir.
Devo usar uma API comercial ou hospedar um modelo local?
Uma API comercial costuma reduzir o trabalho de infraestrutura e facilitar o início, mas cria dependência de preço, disponibilidade e política de dados do fornecedor. Hospedar localmente oferece mais controle, porém exige capacidade de hardware, operação e atualização. Compare custo total e requisitos de privacidade, não apenas o preço por token.
Como evitar que o modelo invente respostas?
Não existe configuração que elimine completamente esse risco. Restrinja a tarefa, forneça fontes relevantes, peça referências quando apropriado e valide a resposta com código ou revisão. Para dados que precisam ser exatos, consulte uma fonte estruturada em vez de pedir ao modelo que os memorize.
Usar IA para programar reduz a necessidade de testes?
Não. Como o código pode parecer plausível mesmo quando está errado, testes independentes ficam ainda mais importantes. Inclua testes de unidade, integração e segurança conforme o risco, e revise a solução como revisaria qualquer contribuição externa.
A Lisbon AI Week, conforme o relato do Observador.pt, mostrou uma mudança importante: já não basta perguntar o que a tecnologia consegue fazer. Para equipes de desenvolvimento, a pergunta prática é se a aplicação resolve um problema real com qualidade, custo previsível e responsabilidade clara. Eu começaria pequeno, mediria com dados próprios e manteria a possibilidade de voltar atrás.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.