Como preservar contexto em produtos com IA

Preservar contexto em produtos com inteligência artificial não é guardar mais histórico. É decidir o que ainda representa a realidade do usuário, o que venceu e o que não deveria influenciar a resposta, mesmo estando disponível.

Quando essa separação não existe, a continuidade vira risco. A IA parece lembrar bem, mas pode reutilizar uma intenção antiga, uma informação desatualizada ou um dado fora da finalidade esperada pelo produto.

Continuidade de experiência não significa lembrar tudo

Um usuário volta ao produto alguns dias depois e espera continuidade. Ele não quer explicar tudo de novo, refazer escolhas já tomadas ou corrigir uma recomendação que ignora o histórico recente. Essa expectativa é legítima. Produtos SaaS sempre trabalharam com algum tipo de continuidade: preferências salvas, registros de atividade, status de tarefas, permissões, comentários, decisões anteriores.

A diferença, em uma funcionalidade com IA, é que o histórico não aparece apenas como dado consultável. Ele pode influenciar uma resposta, priorizar uma recomendação, alterar o tom de uma explicação ou fazer o sistema assumir uma intenção.

Sem essa política, memória vira um rótulo amplo demais para decisões que precisam de regra.

Memória em produto com IA não deve ser tratada como uma gaveta onde tudo entra. Ela precisa funcionar como uma política de contexto: quais informações podem continuar disponíveis, por quanto tempo, em qual tarefa, com qual efeito e sob qual regra de revisão.

A Anthropic define engenharia de contexto como a seleção e manutenção das informações disponíveis ao modelo durante a inferência. Esse conjunto inclui instruções, ferramentas, dados externos e histórico, dentro de uma janela limitada de contexto Anthropic. Essa definição ajuda a tirar o tema do campo abstrato. Contexto não é lembrança ilimitada. É uma seleção operacional.

Para uma liderança de produto, a pergunta prática não é “como fazer a IA lembrar mais?”. A pergunta melhor é: “o que o produto está autorizado a reutilizar nesta interação?”.

Essa mudança evita dois erros comuns. O primeiro é tratar qualquer histórico como sinal útil. O segundo é resolver todo incômodo de continuidade com mais armazenamento, mais resumo ou mais recuperação de dados. Em muitos casos, o produto não precisa lembrar mais. Precisa esquecer melhor.

As três classes de contexto em produtos com IA

Uma política simples de contexto pode começar com três classes: informação útil, informação obsoleta e informação indevida.

Informação útil é aquela que melhora a próxima interação e ainda representa a realidade do usuário, da conta ou da tarefa. Pode ser uma preferência declarada, uma decisão recente, uma configuração ativa, uma restrição operacional ou um objetivo que continua válido. O ponto não é a informação ser interessante. É ela ter finalidade clara e efeito permitido na experiência.

Informação obsoleta já foi útil, mas perdeu validade. Isso pode acontecer por tempo, mudança de estado, nova decisão, alteração de responsável, encerramento de uma tarefa ou troca de prioridade. O histórico continua verdadeiro como registro do passado, mas deixa de ser adequado como base para uma recomendação atual.

Informação indevida é a mais delicada. Ela não deve ser usada mesmo que pareça preditiva. Pode ser sensível, inferida sem clareza, capturada para outra finalidade, obtida fora do escopo da interação ou impossível de corrigir pelo usuário. O risco aqui não é apenas técnico. É de confiança, governança e desenho de produto.

Essa taxonomia é uma proposta aplicada deste guia. Ela não vem pronta de uma ferramenta, nem depende de um modelo próprio. Um produto maduro pode usar modelos de terceiros, busca, regras, resumos de histórico ou agentes. A maturidade está menos na arquitetura escolhida e mais na capacidade de dizer quais informações entram, expiram ou são bloqueadas.

Isso também evita confundir contexto com personalização genérica. Personalizar uma interface pode significar ordenar opções, adaptar linguagem ou antecipar uma necessidade. Preservar contexto, neste artigo, é mais específico: manter informações disponíveis para que uma interação futura faça sentido sem violar validade, finalidade ou controle.

Se você está decidindo onde usar memória em uma funcionalidade, vale conectar esta discussão a uma visão mais ampla de produto em Inteligência no produto: como evoluir um software com IA. Aqui, o recorte é menor e mais operacional: classificar o que pode influenciar a próxima resposta.

Critérios para decidir o que entra no contexto

Uma informação não deveria entrar no contexto só porque está disponível no banco de dados ou no histórico de conversa. Antes de reutilizá-la, o produto precisa passar por alguns critérios.

• Finalidade da tarefa: a informação foi criada para a mesma finalidade da interação atual?
• Atualidade: ela ainda representa o estado do usuário, da conta ou da tarefa?
• Origem do dado: veio de uma declaração explícita, de um comportamento observado, de uma integração, de um resumo ou de uma inferência?
• Permissão de uso: existe regra clara para usar essa informação neste tipo de resposta?
• Impacto sobre a resposta: a IA mudaria uma decisão, recomendação ou ação com base nesse dado?
• Possibilidade de correção: o usuário consegue ver, contestar ou atualizar a informação?
• Custo de manutenção: manter essa informação disponível aumenta complexidade, latência, ambiguidade ou risco sem ganho claro?

O critério mais subestimado é o impacto. Se a resposta da IA não piora de forma relevante quando a informação é removida, talvez ela não deva ocupar contexto. Guardar informação sem efeito claro cria ruído e dificulta auditoria. O produto passa a ter uma memória que ninguém consegue explicar.

Outro critério forte é a correção pelo usuário. Quando uma informação influencia a experiência, mas o usuário não sabe que ela está sendo usada, a continuidade pode parecer adivinhação. Às vezes isso encanta em uma demonstração. Em operação, pode gerar desconfiança.

Não se trata de mostrar toda a lógica interna da IA. Trata-se de permitir que o usuário corrija as premissas relevantes. Uma preferência declarada pode aparecer como configuração editável. Um objetivo ativo pode ser confirmado antes de orientar uma recomendação. Um dado inferido pode exigir validação antes de persistir.

Esse raciocínio conversa com decisões maiores de adoção. Uma boa estratégia de inteligência artificial conectada ao negócio não deveria começar pela pergunta “qual modelo usar?”, mas por quais decisões do produto serão ampliadas, limitadas ou revistas com IA.

Validade e expiração precisam ser desenhadas por tipo de dado

Contexto precisa de prazo ou condição de expiração. Sem isso, o produto transforma passado em presente por padrão.

Algumas informações podem durar até alteração explícita. Uma preferência de idioma, um formato de relatório ou uma configuração de notificação tendem a permanecer válidos enquanto o usuário não muda. Ainda assim, o produto deve permitir revisão.

Outras informações precisam expirar por evento. Um status operacional deixa de orientar a resposta quando a tarefa muda de fase. Uma prioridade de conta pode perder validade quando muda o responsável. Uma oportunidade marcada como crítica deixa de ter o mesmo peso quando é fechada, cancelada ou reclassificada.

Há também informações que devem expirar por sessão. Uma intenção capturada durante uma interação pode ser útil por alguns minutos ou durante uma tarefa específica, mas não necessariamente na semana seguinte. O usuário pode ter perguntado algo por curiosidade, teste, comparação ou exceção. Transformar isso em preferência persistente é uma forma silenciosa de deformar a experiência.

A regra, portanto, deve ser definida por tipo de dado, não por tecnologia. “Resumo de histórico” não é uma política. “Guardar as últimas interações” também não. Uma política precisa dizer que tipos de informação permanecem, quando expiram e o que acontece quando ficam ambíguas.

Um bom desenho pode separar pelo menos quatro ações:

• usar automaticamente quando a informação é útil, válida e dentro da finalidade;
• pedir confirmação quando a informação é útil, mas sensível, ambígua ou de alto impacto;
• rebaixar quando a informação pode aparecer como histórico, mas não deve orientar a recomendação;
• bloquear quando a informação é indevida para aquela interação.

A palavra rebaixar é útil. Nem toda informação obsoleta precisa ser apagada do histórico. Muitas vezes ela deve apenas deixar de influenciar a resposta. O registro continua existindo para consulta, auditoria ou explicação, mas não serve mais como sinal ativo.

Essa distinção ajuda a evitar uma falsa escolha entre lembrar e apagar. Produtos com IA precisam de mais estados intermediários: ativo, expirado, pendente de confirmação, visível apenas como histórico, bloqueado para inferência.

Exemplo fictício: contexto em um assistente de gestão de contas

Imagine um exemplo fictício: um produto SaaS tem um assistente que ajuda gerentes de contas a priorizar clientes durante a semana. O assistente pode consultar histórico de interações, status do funil, tarefas abertas, notas internas e preferências de acompanhamento.

Uma informação útil poderia ser: “esta conta tem uma renovação em andamento e o responsável marcou a próxima ação como reunião de alinhamento”. Se esse status ainda estiver ativo, a IA pode usá-lo para sugerir preparação, listar pendências e lembrar materiais necessários. A informação tem finalidade clara, origem conhecida e relação direta com a tarefa.

Uma informação obsoleta poderia ser: “o cliente demonstrou interesse em expandir o uso do produto”. Isso pode ter sido verdadeiro em uma conversa anterior, mas perdeu validade se a oportunidade foi encerrada, se o contato mudou ou se uma decisão posterior indicou pausa. O erro não está em manter o registro. O erro está em usá-lo como se ainda fosse sinal prioritário.

Uma informação indevida poderia ser uma inferência comportamental sobre o humor, urgência ou perfil pessoal de um contato, derivada de mensagens ou padrões de resposta, sem regra explícita de uso e sem possibilidade de correção. Mesmo que pareça ajudar a priorizar contas, esse tipo de dado pode extrapolar a finalidade do produto. Nesse caso, o produto deveria bloquear a informação para recomendação, não apenas escondê-la da interface.

Agora imagine que o assistente recomenda: “priorize a Conta A porque há alto potencial de expansão”. Essa recomendação só é aceitável se o potencial estiver baseado em dados atuais, permitidos e relacionados à finalidade da tarefa. Se vier de uma intenção antiga, o produto está usando contexto obsoleto. Se vier de uma inferência indevida, o produto está usando uma informação que não deveria orientar a resposta.

Os efeitos desse desenho seriam hipóteses a medir, não resultados presumidos. A equipe poderia observar se recomendações baseadas em contexto válido recebem menos correções, se confirmações reduzem ações indesejadas e se bloqueios evitam usos fora da finalidade. Mas nada disso deve ser assumido como ganho automático de retenção, conversão ou satisfação.

O exemplo também mostra por que a discussão não é apenas técnica. A decisão sobre contexto muda a experiência do usuário, o trabalho da equipe de produto, o desenho de permissões e a confiança na funcionalidade. A confiança depende de o produto explicar quais premissas influenciaram a recomendação e permitir revisão quando necessário.

Revisar contexto como parte da confiabilidade da funcionalidade

Quando uma IA responde mal por causa de contexto vencido ou indevido, não é apenas um erro de prompt. Pode ser uma falha de confiabilidade do produto.

O Google SRE define objetivos de nível de serviço como metas de confiabilidade que orientam decisões de engenharia. A abordagem pressupõe acordo sobre metas, uso do orçamento de erro para priorização e um processo de revisão Google SRE. A aplicação ao contexto é uma interpretação de produto: se a funcionalidade depende de contexto para responder bem, erros de contexto precisam entrar na rotina de confiabilidade.

Isso não exige transformar toda equipe de produto em equipe de Site Reliability Engineering. Exige criar categorias de falha que possam ser revisadas:

• resposta baseada em informação expirada;
• recomendação influenciada por dado fora da finalidade;
• uso de histórico sem possibilidade de correção pelo usuário;
• ausência de confirmação em informação ambígua;
• bloqueio excessivo que impede continuidade legítima;
• resumo de histórico que removeu uma decisão relevante.

Essas categorias permitem priorizar trabalho. Se muitos erros vêm de expiração mal definida, o problema está nas regras de validade. Se vêm de uso indevido, o problema pode estar em governança de dados e finalidade. Se vêm de falta de correção, o problema está na experiência.

A Microsoft descreve sua plataforma de experimentação como uma forma de incorporar experimentação ao ciclo de desenvolvimento, validar hipóteses, medir impacto e iterar produtos Microsoft. Isso não significa que feedback do usuário retreine modelos automaticamente, nem que todo ajuste de contexto seja um experimento estatístico complexo. Mas reforça uma disciplina útil: mudanças em contexto devem ser tratadas como hipóteses de produto, com efeito observado e revisão.

Separar descoberta, hipótese e experimento evita confusão. Descoberta é perceber que usuários corrigem muitas recomendações. Hipótese é propor que parte dessas correções vem de contexto obsoleto. Experimento é testar uma mudança específica de expiração ou confirmação e medir se o comportamento melhora sem criar novos riscos.

Critérios antes de reutilizar contexto

Antes de implementar memória persistente, resumo de histórico, recuperação de dados externos ou personalização baseada em comportamento, use estes critérios. Eles não substituem revisão técnica, jurídica ou de segurança quando necessária, mas ajudam a colocar a decisão no lugar certo.

• A informação ainda representa o estado atual do usuário, da conta ou da tarefa? Se sim, pode ser candidata a contexto útil. Se não, trate como obsoleta.
• A informação foi criada para a mesma finalidade da interação atual? Se sim, pode avançar. Se não, exige nova justificativa ou bloqueio.
• O usuário consegue entender ou corrigir o uso dessa informação? Se sim, há mais controle de experiência. Se não, o risco de uso indevido aumenta.
• Existe um evento que torna essa informação inválida? Exemplos: mudança de plano, fechamento de oportunidade, troca de responsável ou atualização de política.
• Existe um prazo após o qual essa informação perde força? Preferências estáveis podem durar mais. Intenções de sessão devem durar menos.
• A informação é sensível, inferida ou obtida fora da finalidade principal do produto? Se sim, trate como indevida até existir regra explícita permitindo uso.
• A resposta da IA piora de forma relevante se essa informação for removida? Se não piora, a informação provavelmente não deve ocupar contexto. Se piora, documente por que ela é necessária.

O checklist força uma conversa que muitas equipes deixam implícita. Quem decide a validade? Quem revisa exceções? Quem pode alterar a regra? O que acontece quando a IA usa uma informação que deveria ter expirado?

Essas perguntas também ajudam a maturar o roadmap. Em vez de priorizar “memória da IA” como uma funcionalidade genérica, a equipe passa a priorizar capacidades específicas: expiração por evento, confirmação de premissas, bloqueio por finalidade, visibilidade de contexto ativo, revisão de falhas.

Esse tipo de decisão combina bem com um roadmap de IA que organiza oportunidades por valor, risco e capacidade operacional. Memória sem governança pode parecer avanço. Contexto bem classificado oferece uma base mais revisável para evoluir.

Usar, confirmar, rebaixar ou bloquear

A decisão de produto pode ser resumida em quatro estados operacionais.

Use automaticamente quando a informação é útil, atual, permitida e compreensível. Peça confirmação quando ela é útil, mas sensível, ambígua ou de alto impacto. Rebaixe para histórico quando ela é obsoleta e não deve orientar a resposta atual. Bloqueie por regra quando ela é indevida para aquela interação, não apenas quando deve sair da interface.

Essa é a diferença entre um produto que acumula memória e um produto que preserva contexto. O primeiro tenta lembrar tudo e espera que a IA resolva a ambiguidade. O segundo define as condições para que lembrar seja uma escolha segura, útil e revisável.

Um exercício prático é escolher uma interação relevante e classificar as informações que a IA usa em três grupos: úteis, obsoletas e indevidas. Depois defina validade, expiração, responsável pela revisão e efeito permitido na experiência.

Se quiser discutir essa decisão no contexto da sua empresa, converse com a dooop.

Leituras para continuar

• Como acompanhar o custo por tarefa de uma funcionalidade inteligente
• Como desenhar uma funcionalidade de busca com IA

Fontes

• Anthropic: Effective context engineering for AI agents
• Anthropic: Building effective agents
• Google SRE: Implementing SLOs
• Microsoft Research: Experimentation Platform