Por que times de produto ainda não sabem pedir IA — e arquitetura é o elo que falta

Times de produto estão acostumados a pedir software. Ainda estão aprendendo a pedir IA.

Essa é uma das diferenças mais importantes que observei nos últimos anos quando trabalho com organizações na adoção de Inteligência Artificial em produtos reais.

Com software tradicional, a dinâmica costuma ser relativamente conhecida:

• Produto define escopo
• Design desenha experiência
• Engenharia implementa
• QA valida
• Operação monitora
• Se der erro, o erro é explícito

Com IA, muita coisa muda.

A tecnologia é probabilística. A fronteira entre “funciona” e “não funciona” é difusa. Casos raros importam muito. Qualidade pode variar de acordo com a entrada. Expectativa do usuário é outra. E, principalmente, o “caminho feliz” já não é mais suficiente para dizer se um recurso é bom ou não.

E é exatamente nessa transição que muitos times travam.

O problema do pedido genérico de IA

Existe uma frase muito comum em reuniões de produto nos últimos anos:

“Vamos colocar IA aqui.”

Essa frase parece um direcionamento.

Na prática, costuma ser apenas um desejo.

Porque ela não responde perguntas fundamentais como:

• Qual comportamento inteligente queremos habilitar?
• Em quais casos de uso isso realmente ajuda?
• Qual resultado estamos tentando melhorar?
• O que acontece se a resposta ficar errada?
• Qual é o papel do humano nesses casos?
• Como medir se a “melhora” realmente aconteceu?
• Quais dados podemos usar e quais não podemos?
• Qual custo operacional é aceitável?

Sem essas respostas, a arquitetura não tem base para tomar decisões.

A engenharia começa a construir algo vago. O negócio espera um resultado mágico. O usuário final recebe um recurso que parece avançado, mas não resolve nada de maneira confiável.

Software tradicional é explícito. IA é negociada.

Em software tradicional, quando produto pede “adicione um botão que exporta um relatório em PDF”, é razoavelmente claro o que precisa acontecer.

Pode haver discussão de detalhe, mas o problema é, na maior parte do tempo, explícito.

Já quando produto pede “adicione um assistente de IA que ajuda o usuário a preencher essa etapa”, a definição do problema não está pronta.

Ela ainda precisa ser negociada entre:

• O que é possível tecnicamente
• O que é aceitável do ponto de vista de risco
• O que sustenta do ponto de vista de custo
• O que é desejável do ponto de vista de experiência
• O que é governável do ponto de vista operacional

E é nesse espaço que a arquitetura não pode ser apenas “a área que executa”.

Precisa ser o elo que estrutura a decisão.

Por que arquitetura é o elo que falta nessa conversa

Quando produto, negócio e tecnologia falam de IA em línguas diferentes, o papel do arquiteto não é só desenhar caixinhas.

É traduzir intenção em estrutura.

É pegar um pedido vago como “vamos colocar IA no suporte” e transformar isso em decisões que podem ser construídas, medidas e governadas:

• O assistente apenas sugere respostas ou age sozinho?
• Quais tópicos ele pode responder?
• Quais tópicos exigem humano?
• Quais fontes internas ele pode consultar?
• Como detectar que a resposta provavelmente está ruim?
• Como escalar para revisão humana?
• Como garantir conformidade com regulamentação?
• Qual latência máxima é aceitável?
• Qual custo por interação cabe no negócio?
• Como medir sucesso?

Sem essa tradução, produto pede “mais inteligência”. Negócio pede “menos custo”. Engenharia pede “menos risco”. E ninguém consegue avançar de verdade.

O erro de tratar IA como feature e não como capacidade

Outro padrão que causa muita frustração é organizar a adoção da IA como se fosse uma lista de features.

• Sprint 1: colocar chat no app
• Sprint 2: colocar resumo de página
• Sprint 3: colocar gerador de resposta rápida
• Sprint 4: colocar redação automática de email

Isso dá a impressão de avanço.

Mas, na maior parte das vezes, gera um conjunto de capacidades desalinhadas, sem padrão, sem observabilidade comum, sem governança comum e sem alavancagem técnica.

No final, cada “feature de IA” é um mini-projeto isolado.

E cada um deles reinventa:

• Controle de contexto
• Tratamento de erro
• Guardrails
• Observabilidade
• Autorização
• Custos
• Avaliação de qualidade

Uma arquitetura de IA forte funciona exatamente ao contrário.

Ela começa por definir capacidades compartilhadas:

• Como recuperamos contexto
• Como invocamos modelos
• Como tratamos permissão
• Como registramos auditoria
• Como medimos custo
• Como avaliamos qualidade
• Como protegemos dados sensíveis
• Como desenhamos fallbacks

Em cima disso, as “features” surgem como casos de uso específicos, com muito menos risco e muito mais velocidade.

As perguntas certas para produto começar a pedir IA melhor

Se o time de produto ainda não sabe como começar, eu costumo sugerir um roteiro muito pragmático.

Antes de falar em tecnologia, responder juntos:

Qual problema estamos resolvendo?

Não “como usar IA”. Qual problema real.

É reduzir tempo de atendimento? É reduzir retrabalho de operação? É acelerar onboarding? É melhorar conversão em uma etapa específica? É diminuir erros em um processo repetitivo?

Sem problema claro, IA vira demoday.

O que sucesso significa?

Tem que ser algo mensurável.

Redução de X% em tempo médio. Aumento de Y% em acerto da etapa. Queda de Z% no retrabalho. Economia de N horas por semana.

Sem isso, fica impossível priorizar trade-offs.

Qual é o risco máximo aceitável?

Qual é o pior comportamento que a IA pode ter e ainda assim é aceitável?

Onde ela nunca pode errar? Quem revisa quando houver dúvida? Qual ação precisa sempre de confirmação?

IA não existe sem aceitar algum nível de incerteza.

Mas incerteza desenhada é diferente de incerteza negligenciada.

O que o humano faz nessa história?

Quantos times esquecem essa pergunta.

A IA é assistente, tomadora de decisão ou recomendadora? O usuário corrige a resposta? A operação revisa? Há aprovação em duas etapas nos casos críticos?

Desenhar o papel do humano com clareza é o que separa um recurso útil de um risco operacional.

Quando arquitetura entende de produto e produto entende de arquitetura

As melhores iniciativas de IA que vi nasceram de uma colaboração muito próxima entre:

• Produto, defendendo valor e experiência
• Arquitetura, defendendo estrutura, risco e sustentação
• Negócio, defendendo resultado e viabilidade
• Operação, defendendo o mundo real

Nesses casos, IA não é um pedido que cai de cima para baixo.

É um problema que se desenha coletivamente.

E a arquitetura surge como linguagem comum.

Ela transforma:

• “Queremos um assistente inteligente” em componentes, limites e políticas.
• “Queremos reduzir custos” em trade-offs entre modelo, cache, processamento e qualidade.
• “Queremos lançar rápido” em fases bem desenhadas, com superfície de risco controlada.

Reflexão final

Times de produto vão continuar aprendendo a pedir IA por muito tempo.

Isso é normal.

A tecnologia muda rápido, e o modelo mental de produto tradicional ainda não foi completamente atualizado para lidar com sistemas probabilísticos.

Mas o grande pulo do gato não está só em produto aprender mais sobre modelo, prompt ou RAG.

Está em arquitetura se tornar um parceiro ativo da definição do problema.

Não é só “receber o pedido e construir”.

É “participar da tradução do valor de negócio em capacidade operável”.

Porque no fim, a IA que dá certo em produção não é a mais tecnicamente sofisticada.

É aquela para a qual a organização inteira foi capaz de desenhar, junto, qual problema resolve, como medir sucesso e qual risco aceita correr.

E essa tradução dificilmente acontece sem uma boa arquitetura no meio da conversa.