Memória de agentes de IA: separar contexto, preferências e factos persistentes e decidir quando expiram

Recordar não significa conservar o histórico

Um agente que atende a mesma pessoa ou equipa em várias ocasiões necessita de continuidade: pode ser razoável recordar um idioma preferido, o formato habitual de uma entrega ou o nome de um projeto. Contudo, converter todas as conversas, documentos recuperados e inferências do modelo em memória reutilizável introduz um problema de governação. O sistema pode recuperar informação irrelevante, desatualizada, incorreta, sensível ou aplicável apenas a uma circunstância anterior.

A questão de arquitetura não é se o agente tem memória, mas sim que afirmação concreta conserva, quem a pode usar, para que fim e durante quanto tempo. Uma frase como «o cliente prefere aprovar as alterações por e-mail» pode ser uma preferência declarada, uma observação deduzida de uma única interação ou uma regra operacional em vigor. Estas interpretações têm valores distintos e não devem ser armazenadas nem aplicadas da mesma forma.

A memória persistente também não adquire autoridade por ter sido armazenada. Uma instrução presente numa conversa passada, num documento importado ou num resultado de recuperação continua a ser conteúdo da fonte que a forneceu. Não deve substituir instruções de maior autoridade nem permitir ações que o agente não pode realizar no contexto atual. Esta separação é especialmente importante quando o conteúdo recuperado não foi validado ou pode ter sido manipulado.

Para orientar este guia, convém distinguir factos de conceção de decisões de política. É um facto operacional que um sistema pode atribuir datas de criação, revisão ou expiração a registos. Em contrapartida, decidir que uma preferência expira ao fim de noventa dias é uma política da organização: deve justificar-se pelo risco, pela volatilidade do dado e pela experiência esperada, e não ser apresentada como uma regra universal.

Quatro objetos que convém separar

A palavra «memória» costuma misturar componentes com ciclos de vida muito diferentes. Separá-los reduz recuperações indevidas e torna o comportamento do agente mais compreensível. O contexto de sessão contém a interação imediata que permite interpretar o pedido atual. Deve estar limitado à sessão e desaparecer ou ficar inacessível no seu término, salvo se uma parte for promovida deliberadamente para outra categoria.

O estado da tarefa representa o progresso de um trabalho concreto: identificador de um pedido, elementos já processados, rascunho em curso, resultado parcial ou passo pendente. Pode precisar de sobreviver a uma breve interrupção, mas nem por isso é uma preferência ou um facto que deva estar disponível em tarefas futuras. A documentação de ferramentas de execução para agentes da Google oferece um exemplo de estado de fluxo de trabalho ligado a uma sessão e de limpeza explícita ou através de tempo de vida no fim da tarefa ou da conversa.

A memória declarada é a informação que uma pessoa ou equipa forneceu para manter continuidade, como o idioma preferido, um fuso horário ou uma convenção de nomenclatura. Deve conservar a declaração original ou uma referência a ela, além do seu âmbito. Uma configuração indicada para um projeto não tem de se estender a todos os projetos, nem uma preferência de um membro da equipa deve ser atribuída a toda a organização.

O conhecimento recuperável reúne afirmações obtidas de fontes identificadas: uma política interna em vigor, o estado de um serviço ou uma lista de responsáveis. A sua conceção assemelha-se menos a um perfil de utilizador e mais a um registo de proveniência: fonte, versão ou momento da consulta, responsável, alcance e condições de atualização. A ontologia PROV-O do W3C fornece conceitos para representar entidades, atividades e agentes, bem como relações de geração, derivação e invalidação. Não obriga à adoção de uma base de dados específica, mas ajuda a explicitar a rastreabilidade.

O registo mínimo de uma memória governável

Um registo não precisa de guardar o texto conversacional completo para ser útil. Em muitos casos, basta uma afirmação normalizada e metadados. Por exemplo, em vez de conservar um diálogo inteiro, um registo pode indicar que uma pessoa escolheu receber resumos em espanhol para um espaço de trabalho específico. A redução de conteúdo não elimina todos os riscos, mas limita a exposição e facilita a inspeção.

No mínimo, cada elemento deve incluir um identificador estável; conteúdo ou referência ao conteúdo; proprietário ou sujeito a quem é atribuído; finalidade permitida; âmbito de aplicação; fonte e modo de obtenção; nível de confiança; data de criação; data da última verificação; regra de expiração; e estado de eliminação ou restrição. Se derivar de outros dados, deve também guardar as suas dependências. Assim, é possível localizar que memórias devem ser revistas quando uma fonte muda ou quando uma pessoa pede retificação.

Convém distinguir o nível de confiança da autorização de utilização. Uma preferência declarada diretamente pela pessoa pode ter confiança elevada relativamente ao que ela expressou, mas um âmbito limitado. Um dado extraído automaticamente de um documento pode ser potencialmente útil, mas exigir validação humana ou consulta da fonte primária antes de acionar uma ação. A confiança não deve transformar-se numa pontuação opaca que substitua a proveniência.

Para informação pessoal, o Regulamento Geral sobre a Proteção de Dados da União Europeia estabelece princípios de limitação da finalidade, minimização, exatidão e limitação do prazo de conservação, além de direitos relacionados com retificação, apagamento e limitação do tratamento nas condições aplicáveis. Um produto que opere neste enquadramento deve traduzir esses princípios em processos reais; acrescentar um campo chamado «TTL» não demonstra, por si só, conformidade jurídica.

O que pode persistir e o que deve desaparecer

A persistência deve ser decidida pela necessidade funcional e pelo risco, não pela facilidade de armazenamento. Uma preferência explícita e de baixo impacto pode persistir se tiver um titular claro, uma finalidade concreta e uma forma acessível de a editar. Um estado de tarefa costuma ser eliminado quando o trabalho termina. Um facto externo variável, como uma tarifa, uma política ou a disponibilidade de um serviço, pode ser conservado como pista de recuperação, mas não deve ser tratado como prova atual quando vai ser tomada uma decisão relevante.

As inferências merecem uma categoria separada. O facto de o modelo ter deduzido que alguém prefere comunicações curtas não equivale a essa pessoa tê-lo declarado. Se o produto decidir guardar inferências, deve identificá-las como tal, reduzir o seu âmbito, definir uma revisão breve e oferecer um mecanismo simples para as confirmar, corrigir ou descartar. Em cenários de impacto elevado, é mais prudente não converter inferências comportamentais em memória persistente sem uma decisão explícita de produto e uma avaliação de riscos.

Os dados sensíveis exigem uma avaliação mais rigorosa do que ajustes de apresentação. A sensibilidade depende tanto da natureza do dado como do contexto, do destinatário, da finalidade e da jurisdição. Este guia não substitui a análise jurídica nem a análise de segurança. Como critério de produto, a presença de um dado sensível não justifica a sua persistência: a equipa deve demonstrar uma finalidade concreta, controlos de acesso, conservação limitada e um processo eficaz para tratar alterações ou eliminação quando aplicável.

Também é importante não ocultar esta classificação sob uma única etiqueta de «memória». A interface e as APIs internas devem refletir as diferenças: um utilizador pode querer editar uma preferência, cancelar uma tarefa em pausa ou questionar a exatidão de um facto proveniente de uma fonte externa. São operações distintas e exigem rastos distintos.

Expiração: prazo, revisão e eventos

Uma data de expiração responde à pergunta sobre quando deixar de recuperar um dado automaticamente. Uma revisão obrigatória responde a outra: quando deve ser novamente verificado antes de ser considerado válido. Ambas podem coexistir. Por exemplo, uma preferência de formato pode continuar disponível até que a pessoa a modifique ou elimine, enquanto uma política operacional pode manter-se indexada, mas exigir consulta da respetiva fonte antes de ser usada para aprovar uma ação.

As regras baseadas em eventos complementam o relógio. Uma mudança de projeto, função, fornecedor, conta ou versão documental pode invalidar memórias associadas. Se uma afirmação depende de uma fonte concreta, atualizar ou retirar essa fonte deve desencadear uma revisão dos seus derivados. Modelar derivações e invalidações permite encontrar o conjunto afetado em vez de esperar que cada elemento expire separadamente.

A expiração não deve ser confundida com apagamento físico imediato. Por motivos operacionais ou normativos, podem existir estados distintos, como «não recuperável», «pendente de eliminação» ou «retido sob uma política específica». O essencial para o comportamento do agente é que um elemento expirado ou restrito não volte a entrar silenciosamente no contexto de resposta. A implementação deve documentar quem pode aceder a cada estado e para que finalidade.

Os prazos concretos não podem ser deduzidos de uma fonte técnica geral. Devem resultar da finalidade, do tipo de dado, do risco de desatualização, das obrigações aplicáveis e das necessidades operacionais. Uma equipa pode definir classes de retenção, mas deve medir os seus efeitos: quantas memórias expiram sem uso, quantas são corrigidas e quantas recuperações são bloqueadas por falta de vigência.

Conflitos: instruções atuais, preferências e fontes

Um conflito frequente surge quando uma preferência recordada contradiz o pedido presente. A regra operacional mais simples é que o pedido atual da pessoa, dentro dos limites de autorização e segurança do sistema, prevalece sobre uma preferência anterior. Se alguém pediu anteriormente respostas curtas, mas agora solicita uma análise detalhada, o agente deve atender ao pedido atual e, se for adequado, oferecer a atualização da preferência em vez de a alterar silenciosamente.

A hierarquia de instruções é independente da memória. A especificação de modelos da OpenAI descreve níveis de autoridade para instruções e indica que conteúdo não confiável não ganha autoridade por surgir em dados fornecidos ou recuperados. Por conseguinte, uma instrução armazenada em memória declarada ou incorporada a partir de um documento não pode anular regras de maior autoridade. A conceção deve preservar a origem de cada instrução e evitar que a recuperação a apresente como uma ordem do sistema.

Quando duas fontes de conhecimento divergem, o agente não deve resolver a discrepância inventando uma síntese. Deve identificar a existência do conflito, preferir uma fonte primária ou mais recente de acordo com uma política definida, ou pedir intervenção humana se a decisão tiver consequências relevantes. O registo de memória deve assinalar os elementos em causa para que não sejam reutilizados como factos estabelecidos.

A correção tem duas dimensões. Corrigir o registo principal impede que o dado continue a surgir em novas recuperações. Corrigir os seus derivados impede que sobreviva em resumos, índices, caches, avaliações ou dados de treino de recuperação, conforme a arquitetura. Um processo de retificação ou eliminação que apenas atualiza uma tabela visível, mas deixa o dado nos índices que alimentam o agente, não cumpre o objetivo operacional de impedir a sua reutilização.

Revalidar antes de uma ação externa

A memória pode ajudar a formular uma resposta, mas nem sempre é suficiente para realizar uma ação externa. Se o agente for enviar informação, modificar um registo, iniciar uma transação, alterar permissões ou tomar uma decisão com impacto, deve avaliar a vigência do dado que condiciona essa ação. Quanto maior for o impacto e mais variável for a fonte, maior deve ser a exigência de consulta ou confirmação.

A evidência de vigência não é uma afirmação genérica de que o registo tem «confiança elevada». Pode ser uma consulta recente à fonte primária autorizada, uma confirmação explícita da pessoa competente ou um dado assinado e ainda válido segundo as regras do domínio. O sistema deve registar que verificação foi realizada, quando, contra que fonte e que decisão permitiu. Se não puder verificá-lo, deve abster-se, reduzir o âmbito da ação ou pedir confirmação.

O projeto OWASP Gen AI Security identifica riscos associados ao envenenamento de memória e contexto em aplicações agênticas. Em termos de conceção, isto reforça a necessidade de separar o conteúdo recuperado das instruções autorizadas, registar a proveniência e observar que memórias influenciaram uma ação. Um filtro semântico, por si só, não garante que uma memória seja fiável nem que seja adequada ao objetivo atual.

O NIST propõe, no seu enquadramento de gestão de riscos de IA, atividades de governação, mapeamento, medição e gestão, incluindo monitorização e documentação durante a operação. Aplicado à memória, isto sugere tratar recuperações falhadas, memórias desatualizadas e correções repetidas como sinais mensuráveis de risco, e não apenas como incidentes isolados de qualidade.

Controlos de produto e testes operacionais

Uma vista de memória não é apenas uma página de configuração. Deve permitir compreender que dados o agente utiliza e distinguir, pelo menos, preferências declaradas, factos recuperáveis, inferências e estados de tarefa quando forem visíveis para a pessoa. Para cada elemento, uma apresentação útil inclui conteúdo compreensível, fonte ou modo de obtenção, âmbito, última revisão, data de expiração e opções de edição, restrição ou eliminação quando aplicável.

O registo de utilização é o complemento técnico dessa vista. Perante uma resposta problemática, a equipa precisa de reconstruir que elementos foram recuperados, quais foram descartados, quais influenciaram a decisão e se houve revalidação. Não é necessário expor internamente todos os dados a todos os operadores: os próprios registos exigem controlos de acesso, minimização e prazos de conservação. A rastreabilidade deve apoiar a investigação sem se tornar noutra memória ilimitada.

Os testes devem abranger mais do que a recuperação correta. Inclua casos em que uma memória antiga contradiz o pedido atual; uma fonte mudou; uma inferência está incorreta; uma preferência pertence a outro projeto; e um elemento eliminado aparece num resumo ou numa cache. Para ações externas, teste que a ausência de evidência válida bloqueia a ação ou solicita uma confirmação adequada.

Meça as taxas de recuperação de memórias expiradas ou fora de âmbito, conflitos detetados e não resolvidos, retificações, eliminações concluídas, bloqueios por falta de revalidação e ações que dependeram de memória. Estas métricas não demonstram, por si só, que o sistema é seguro ou conforme, mas revelam onde a memória se está a tornar uma fonte de decisões defeituosas.

Lista de verificação de implementação

Antes de ativar memória persistente, a equipa deve conseguir responder de forma verificável a várias perguntas: que classes de dados guarda; quem é o seu proprietário; que finalidade justifica cada classe; como a fonte é identificada; quando expira; que eventos a invalidam; quem a pode ver ou alterar; e o que acontece nos índices, caches e resumos quando é corrigida ou eliminada.

A arquitetura não precisa de resolver todos os riscos através de automatização. Em alguns domínios, a resposta correta é restringir a memória a preferências de baixo impacto, manter factos sensíveis fora da persistência do agente ou exigir revisão humana para alterações de elevado impacto. A continuidade operacional não depende de recordar mais, mas de recordar apenas o que pode ser governado.

Para ampliar o enquadramento, relacione esta prática com os conteúdos de Learn sobre conceção de agentes, com Segurança para riscos operacionais e com o Glossário para acordar termos como proveniência, retenção, âmbito e revalidação. Manter um vocabulário comum evita que produto, engenharia, dados e segurança usem «memória» para se referirem a mecanismos incompatíveis.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.