Desenvolvimento de software com inteligência artificial

Quando um diretor pesquisa por desenvolvimento de software com inteligência artificial, ele pode estar atrás de duas coisas bem diferentes. A primeira é usar IA para escrever código mais rápido: copiloto na IDE, geração de testes, revisão automática de pull request. A segunda é construir um produto que tem IA dentro — um sistema em que parte do comportamento é decidida por um modelo, e não por uma regra escrita à mão.

São disciplinas distintas. A primeira mexe na produtividade do time de engenharia. A segunda muda o que significa “pronto”, como se testa, quanto custa rodar e quem precisa estar na equipe. Este texto trata da segunda — construir o produto com o modelo dentro — porque é o que costuma pegar as empresas de surpresa: o software parece o mesmo por fora e se comporta de outro jeito por dentro. Se o seu tema for a empresa aparecer nas respostas de assistentes, o assunto é outro e está em GEO, a otimização para IA generativa.

A diferença central é simples de enunciar e desconfortável de administrar: software tradicional é determinístico. Dada a mesma entrada e o mesmo estado, a saída é a mesma. Software com IA dentro é probabilístico. A mesma entrada pode gerar respostas diferentes, e “correto” deixa de ser um valor único e passa a ser uma faixa aceitável. Quase tudo que muda no ciclo de desenvolvimento decorre disso.

O que muda no ciclo quando o comportamento é probabilístico

Em um sistema convencional, o aceite é binário. O cálculo bate ou não bate, o boleto é emitido ou não é. Em um sistema com modelo no meio, o aceite passa a ser uma distribuição: para este conjunto de casos, o sistema acerta em quase todos, erra de forma tolerável em alguns e não pode errar de jeito nenhum em outros. Definir essas três categorias é trabalho de produto e de negócio, não de infraestrutura.

Três consequências práticas aparecem cedo:

• Bug pode não reproduzir. O relato “ontem ele respondeu errado” pode não se repetir na mesma entrada. Sem registro do que entrou, do que foi recuperado e do que saiu, não há investigação possível.
• O comportamento muda sem alguém tocar no código. Uma nova versão do modelo, uma mudança na base de conhecimento ou um documento novo indexado alteram a saída. Regressão silenciosa é uma das falhas mais difíceis de perceber a tempo nesse tipo de projeto.
• Dado de produção vira insumo de desenvolvimento. O que o usuário realmente pergunta é diferente do que a equipe imaginou. Sem um caminho para trazer esse material de volta ao ciclo, o sistema estaciona na qualidade do primeiro mês.

Requisito vira avaliação, não especificação fechada

A tentação é escrever o requisito do jeito de sempre: “o sistema deve classificar corretamente as solicitações do cliente”. Isso não é testável. O equivalente funcional, em software com IA, é um conjunto de avaliação — o que o mercado chama de eval: casos reais, com a resposta esperada ou com o critério que separa resposta aceitável de resposta ruim.

Quem escreve a avaliação

Não é a engenharia sozinha. Quem sabe distinguir uma boa resposta de uma resposta perigosa é o especialista do domínio: o analista de crédito, o farmacêutico, o coordenador de suporte. O papel da engenharia é transformar esse julgamento em algo executável e repetível a cada mudança. Um projeto que não consegue alocar esse especialista costuma travar por aí, e não por limitação de tecnologia.

O conjunto de avaliação é um ativo

Ele nasce pequeno, com dezenas de casos, e cresce a cada incidente: toda resposta errada que chega da operação vira um caso novo. Com o tempo, esse conjunto passa a ser a parte mais valiosa do projeto, porque é o que permite trocar de modelo, mudar de fornecedor ou reescrever a orquestração sem apostar às cegas. Antes de contratar, vale comparar como esse tipo de projeto é estruturado no mercado; reunimos esse panorama em nosso texto sobre consultoria em inteligência artificial.

A arquitetura típica de um sistema com IA dentro

Modelo é componente, não é o sistema. O que sustenta um produto em produção são cinco camadas que quase sempre aparecem juntas: dado, recuperação, orquestração, guardrail e observabilidade.

Dado e recuperação

A camada de dado responde de onde vem a informação que o modelo usa: base vetorial, banco relacional, documentos, chamadas de API a sistemas internos. A camada de recuperação decide o que entra no contexto de cada requisição. É aqui que a maior parte da qualidade percebida é ganha ou perdida. Um modelo excelente com recuperação ruim entrega resposta confiante e errada, que é o pior resultado possível.

Orquestração e guardrail

A orquestração define a sequência: quando chamar o modelo, quando resolver por regra determinística, quando pedir confirmação humana, o que fazer se a chamada falhar ou demorar. O guardrail é o cinto de segurança: validação de formato de saída, bloqueio de dado sensível, limite de escopo, checagem de permissão do usuário na recuperação — antes de o dado entrar no contexto — e não apenas antes de devolver a resposta. Guardrail não é enfeite de compliance, é o que impede que uma falha rara vire incidente público.

Observabilidade

Observabilidade é registrar entrada, contexto recuperado, versão do modelo, saída, custo e latência de cada requisição. Sem isso não existe depuração, não existe medição de custo real e não existe auditoria. É a camada que mais se corta no piloto e mais falta na produção. Esse desenho é a espinha dorsal dos projetos que conduzimos no BrainPilot, a frente de IA empresarial da Wys. Quem quiser ampliar o repertório em inteligência artificial, busca e arquitetura digital encontra o material do fundador em Aprenda, o hub de estudos do Paul Gomes.

O que testar quando a saída nunca é igual

A pergunta certa não é “como faço teste automatizado disso”, e sim “o que continua sendo determinístico”. Boa parte do sistema continua: contrato de API, formato de saída, permissão, tempo limite, comportamento de fallback quando o provedor de modelo fica fora do ar. Isso se testa como sempre se testou, e é o que evita a maioria dos incidentes.

O que sobra, o miolo probabilístico, pede outro conjunto de práticas:

• Suíte de regressão sobre o conjunto de avaliação, rodada a cada mudança de prompt, de modelo ou de base.
• Testes adversariais: tentativa de injeção de instrução, pedido fora de escopo, tentativa de extrair dado de outro cliente.
• Modo sombra: rodar o sistema novo em paralelo com o processo atual, sem afetar o cliente, comparando as saídas.
• Amostragem humana contínua depois de publicado, com uma fila de revisão que alimenta o conjunto de avaliação.
• Métrica de negócio junto da métrica técnica: taxa de reabertura de chamado, tempo de resolução, retrabalho. Um sistema pode melhorar no papel e piorar na operação.

Custo de inferência é requisito de arquitetura

Em software tradicional, infraestrutura é rateio. Em software com IA, cada operação tem custo variável e mensurável, e esse custo é decidido na arquitetura, não no fim do projeto. Quantas chamadas o fluxo faz por atendimento, qual o tamanho do contexto enviado, se há cache de respostas frequentes, se as perguntas simples são roteadas para um modelo menor, se o pré-processamento determinístico reduz o que o modelo precisa ler — cada uma dessas escolhas mexe direto na conta.

Vale tratar custo por operação como requisito não funcional, ao lado de latência e disponibilidade, com um teto definido antes de começar. O padrão se repete: o piloto é barato porque o volume é pequeno, e a produção não fecha porque o custo por transação supera o valor que a transação gera. Isso não é problema de fornecedor de nuvem, é problema de desenho. Quando o produto usa IA generativa dentro de processos internos, essa conta aparece mais cedo do que se imagina; tratamos desse ponto em nosso texto sobre IA generativa dentro da operação.

Integração com o sistema legado é onde o projeto trava

Em empresa que já opera há anos, o modelo raramente é o gargalo. O gargalo é chegar até o dado e devolver a ação para dentro dos sistemas que já existem. Quatro pontos costumam consumir mais tempo do que a parte de IA propriamente dita:

• Acesso ao dado. ERP sem API decente, campo livre preenchido de um jeito diferente por cada operador, cadastro duplicado, histórico em planilha. Antes de qualquer modelo, alguém precisa normalizar isso.
• Permissão. O sistema com IA não pode enxergar mais do que o usuário logado enxergaria. Isso precisa ser verificado na recuperação, não na resposta final.
• Escrita de volta. Quando o sistema não só responde, mas executa — abre chamado, atualiza pedido, lança crédito —, entram idempotência, trilha de auditoria e caminho de reversão.
• Ritmo. Sistemas antigos não suportam a taxa de chamadas síncronas que um fluxo com IA gera. Fila, processamento assíncrono e limite de vazão entram no desenho desde o começo.

Equipe, prazo e por que o piloto não vira produção sozinho

Quem precisa estar no time

A composição mínima, seja no time interno, seja em uma empresa de desenvolvimento de software com inteligência artificial contratada para o projeto, costuma ser:

• Engenharia de software, porque a maior parte do trabalho continua sendo software convencional.
• Engenharia de dados.
• Alguém responsável pela avaliação e pelo comportamento do modelo.
• Um especialista do domínio com tempo alocado de verdade.
• Um ponto de contato das áreas de segurança e jurídico.
• Um dono de produto com autoridade para decidir o que é aceitável.

A falta de qualquer um desses papéis aparece como atraso, mas a causa é organizacional. Critérios para avaliar quem vai construir isso com você estão em nosso mapa das empresas de inteligência artificial no Brasil.

Por que o piloto não vira produção sozinho

Um piloto é otimizado para demonstrar. Ele roda com dados escolhidos, volume baixo, usuários tolerantes e um humano por perto para corrigir. Produção é o oposto: entrada imprevisível, cauda longa de casos estranhos, usuário sem paciência, custo real, exigência de auditoria e suporte de plantão. A distância entre demonstração e produção costuma ser maior do que a distância entre nada e demonstração, e é nesse ponto que muita iniciativa empaca.

Por isso, prazo em projeto desse tipo se conta por marcos verificáveis, não por semanas no cronograma: conjunto de avaliação aprovado pelo negócio, integração com o legado funcionando com dado real, teto de custo por operação atingido, modo sombra rodando em paralelo, publicação para um grupo restrito, expansão. Quem promete uma data fechada antes de olhar os dados da empresa está chutando.

Continue por aqui

Este texto faz parte de uma série sobre contratar e aplicar inteligência artificial na empresa. Os outros recortes:

• Consultoria de inteligência artificial: o que faz e quando contratar — o panorama do serviço, os quatro tipos de trabalho e como avaliar uma proposta.
• Consultoria em IA generativa — onde a IA que gera texto e código realmente paga dentro da operação — e onde não paga.
• Otimização para IA generativa (GEO) — como uma marca passa a ser citada nas respostas do ChatGPT, do Gemini e das AI Overviews.
• Como avaliar uma empresa especialista em inteligência artificial — os três perfis de fornecedor, as perguntas que separam quem entrega de quem faz demonstração.

Quem assina esta análise

Este texto foi escrito a partir dos projetos que a Wys conduz em desenvolvimento de software com inteligência artificial dentro de operações que já rodavam antes de a IA existir no orçamento. Quem lidera a frente de IA da agência é Paul Gomes, fundador da Wys, que escreve sobre inteligência artificial, busca e arquitetura digital.

Se você está avaliando por onde começar, o diagnóstico de aquisição gratuito ajuda a mapear onde a operação perde eficiência hoje — um jeito mais honesto de escolher o primeiro projeto do que partir da tecnologia.

Perguntas frequentes

Desenvolvimento de software com inteligência artificial é o mesmo que usar IA para programar mais rápido?

Não. Usar IA para programar é ganho de produtividade do time de engenharia, com copiloto de código, geração de testes e revisão automática. Desenvolvimento de software com inteligência artificial, no sentido de engenharia, é construir um produto em que parte do comportamento é decidida por um modelo. O segundo caso muda o que significa estar pronto, como se testa e quanto custa manter o sistema no ar.

Como escrever requisito para um sistema em que a resposta muda a cada execução?

Em vez de uma especificação fechada, o requisito vira um conjunto de avaliação: casos reais com a resposta esperada ou com o critério que separa resposta aceitável de resposta ruim. Esse conjunto é escrito junto com o especialista do domínio, não só pela engenharia, e roda a cada mudança de prompt, de modelo ou de base de conhecimento. É ele que permite dizer se uma alteração melhorou ou piorou o sistema.

Como testar um software com IA se a saída nunca é igual?

Boa parte do sistema continua determinística e se testa como sempre: contrato de API, formato de saída, permissão, tempo limite e comportamento quando o provedor do modelo fica fora do ar. O miolo probabilístico pede suíte de regressão sobre o conjunto de avaliação, testes adversariais, execução em modo sombra ao lado do processo atual e revisão humana por amostragem depois de publicado. As métricas de negócio entram junto das métricas técnicas, porque um sistema pode melhorar no papel e piorar na operação.

Preciso treinar um modelo próprio para ter IA dentro do meu produto?

Na maior parte dos casos empresariais, não. O diferencial costuma estar no dado da empresa, na camada de recuperação, na orquestração e no guardrail, e não no treinamento de um modelo do zero. Ajuste fino faz sentido em cenários específicos, como formato de saída muito rígido ou linguagem técnica de nicho, e mesmo assim depois que a arquitetura em volta já estiver funcionando.

Por que o custo de inferência precisa entrar na arquitetura e não só no orçamento de infraestrutura?

Porque cada operação tem custo variável, decidido por escolhas de desenho: quantidade de chamadas por fluxo, tamanho do contexto enviado, uso de cache, roteamento de perguntas simples para modelos menores e pré-processamento determinístico. Tratar o custo por operação como requisito não funcional, com teto definido antes de começar, evita o cenário em que o piloto é barato e a produção não fecha a conta. Depois que o sistema está construído, mudar esse custo geralmente exige reescrever partes da arquitetura.

Por que tantos pilotos de IA não chegam a virar produção?

Porque o piloto é otimizado para demonstrar: dados escolhidos, volume baixo, usuários tolerantes e alguém por perto para corrigir. Produção exige lidar com entradas imprevisíveis, cauda longa de casos estranhos, permissão por usuário, trilha de auditoria, custo real por transação e suporte. A distância entre demonstração e produção costuma ser maior que a distância entre não ter nada e ter uma demonstração, e é por isso que o prazo se conta por marcos verificáveis, não por datas no cronograma.