O Problema da Portabilidade de Memória IA: Por Que Seu Contexto Está Preso

Depois de três anos usando o ChatGPT, você construiu algo valioso sem perceber. Sua IA sabe que você prefere respostas diretas. Sabe que você é desenvolvedor Python, que trabalha com infraestrutura, que gosta de comentários no código em inglês mesmo falando português. Ela lembra dos nomes dos seus projetos, das suas decisões arquiteturais, do seu estilo de comunicação.

Agora tente levar qualquer coisa disso para o Claude. Ou para o Gemini. Ou para qualquer outra plataforma.

Não dá.

Sim, a maioria das plataformas permite exportar seus dados — logs de conversas, memórias salvas, informações da conta. Mas o que você recebe de volta é matéria-prima, não conhecimento utilizável. Os relacionamentos entre fatos, as inferências construídas ao longo de meses de interação, o contexto que torna uma memória útil — nada disso sobrevive à exportação. E mesmo que sobrevivesse, não existe um formato padrão que outra plataforma pudesse importar. Quando você troca, não perde os dados — perde o entendimento.

Este é o problema da portabilidade de memória IA, e está prestes a se tornar uma das questões mais importantes da indústria.

O novo lock-in não é o modelo — é a memória

Nos últimos dois anos, o foco competitivo em IA esteve nas capacidades dos modelos: benchmarks de raciocínio, tamanho de context window, suporte multimodal. Mas à medida que os modelos convergem em capacidade, a diferenciação real está migrando para outro lugar: a memória.

A OpenAI entendeu isso cedo. Em 10 de abril de 2025, a memória do ChatGPT expandiu de simples fatos salvos para referenciar todo o histórico de conversas do usuário. Em 3 de junho, até usuários gratuitos ganharam uma versão simplificada. A mensagem era clara: quanto mais você usa o ChatGPT, mais difícil fica sair.

Isso não é acidental. Como o CEO da Mem0, Taranjeet Singh, disse ao TechCrunch ao anunciar a captação de US$ 24 milhões: “Memory is becoming one of their key moats now that LLMs are getting commoditized.” Os grandes laboratórios de IA estão construindo sistemas de memória, mas têm pouco incentivo para torná-los portáveis ou interoperáveis. O contexto acumulado é o novo custo de troca.

A dor é real o suficiente para que uma nova categoria de ferramentas tenha surgido. O MemoryPlugin oferece uma extensão de navegador para sincronização de memória cross-platform. O Context Pack ajuda a transferir contexto entre ChatGPT e Claude. O AI Context Flow constrói uma camada universal de contexto entre plataformas de IA. Mas todos estão construindo pontes proprietárias entre silos proprietários — cada um com seu próprio formato, suas próprias limitações, e nenhuma interoperabilidade entre eles.

O que você realmente perde quando troca

Para entender a escala do problema, considere o que uma memória de IA madura contém:

Identidade e preferências. Seu nome, cargo, idioma, estilo de comunicação, preferências de formatação, o quão técnicas você quer as respostas.

Contexto profissional. Sua stack tecnológica, sua empresa, seus projetos, as decisões arquiteturais que você tomou, as restrições dentro das quais trabalha.

Conhecimento relacional. Fatos que só fazem sentido em conexão com outros fatos — que seu projeto usa React porque você avaliou Vue e Svelte primeiro, e essa decisão foi moldada pela experiência do time com TypeScript e pela necessidade de um ecossistema maduro de bibliotecas de UI.

Conhecimento temporal. Coisas que eram verdade em um momento específico — você estava migrando de AWS para GCP no Q3, seu time adotou Kubernetes no Q4, sua empresa reestruturou o time de plataforma em janeiro.

Nenhum desses tipos de conhecimento tem uma representação padronizada. O ChatGPT armazena internamente. O Claude deriva do histórico de conversas. O Gemini usa seu próprio formato. Não existe um equivalente a contacts.vcf para memórias de IA. Nem um calendar.ics. Nem OPML. Nenhum formato universal que qualquer plataforma possa ler e escrever.

Todo mundo fala de memória portável — ninguém entrega o formato

A ironia é que a indústria já concorda que isso é um problema.

A Mem0 se posiciona explicitamente como um “memory passport” — sua memória de IA viajando com você entre apps e agentes, assim como e-mail ou logins. Levantaram US$ 24 milhões com essa visão. Mas a API da Mem0 é um serviço proprietário, não um formato aberto de intercâmbio. Sua memória viaja através da Mem0, não de forma independente.

A Letta (anteriormente MemGPT) criou o formato Agent File (.af) para serializar agentes de IA stateful. Embora o .af inclua seções de memória editável com preferências do usuário e personalidade, ele foi projetado para persistência de agentes entre sessões — não para contexto portável do usuário entre diferentes sistemas de IA.

A Cognee construiu um motor de knowledge graph para memória de agentes de IA. Excelente infraestrutura. Mas quando você ingere dados na Cognee, eles vivem na representação interna dela.

Cada um desses projetos resolve uma parte do quebra-cabeça. Nenhum deles define como um arquivo de memória de IA portável deveria ser. Estão construindo contêineres cada vez mais sofisticados, mas não existe uma etiqueta de envio padrão.

A pressão regulatória já está aqui

Isso não é apenas uma preocupação de desenvolvedores — está se tornando uma questão regulatória.

O EU Data Act, com provisões centrais em vigor desde 12 de setembro de 2025, determina que provedores de serviços em nuvem e processamento de dados facilitem a troca entre provedores, removam barreiras técnicas e contratuais à portabilidade, e suportem formatos padronizados de exportação. As taxas de troca devem ser totalmente eliminadas até janeiro de 2027, e contratos de longo prazo existentes devem ser adaptados até setembro de 2027. A direção é clara: o vendor lock-in de dados de usuários está em rota de colisão regulatória.

O EU AI Act, atingindo aplicação total em agosto de 2026, adiciona requisitos de transparência para sistemas de IA. Enquanto isso, a Comissão Europeia debate ativamente se deve classificar o ChatGPT sob o Digital Services Act — e com o ChatGPT agora se aproximando de 900 milhões de usuários ativos semanais, a revisão programada do DMA em maio de 2026 pode muito bem trazer plataformas de IA generativa para o escopo como uma nova categoria de serviço de plataforma central. Pesquisadores da London School of Economics já argumentaram que isso é necessário para endereçar a dinâmica competitiva do mercado de IA.

A questão não é se as plataformas de IA enfrentarão pressão para suportar portabilidade de memória. É se a indústria define o padrão proativamente, ou se os reguladores impõem um.

O que um padrão real precisa ter

Um formato viável de intercâmbio de memória de IA precisa lidar com diversas coisas que as abordagens existentes não cobrem:

Tipos de memória estruturados. Não apenas dumps de conversas brutas, mas memórias tipadas: fatos, preferências, habilidades, objetivos, relacionamentos, contexto de projeto. Um sistema downstream precisa saber se “Usuário prefere dark mode” é uma preferência ou um fato, porque cada um tem implicações diferentes em como deve ser aplicado.

Proveniência. De onde veio essa memória? Qual plataforma? Qual conversa? Foi explicitamente declarada pelo usuário ou inferida pela IA? Proveniência importa para confiança: uma memória que o usuário digitou deve ter mais peso do que uma que a IA inferiu de um comentário lateral.

Ciclo de vida temporal. Memórias não são permanentes. Uma preferência pode mudar. Um projeto pode terminar. Um fato pode ser superado. Qualquer formato que não modele tempo — criação, expiração, substituição — vai acumular conhecimento obsoleto que degrada a utilidade da IA ao longo do tempo.

Integridade. Se eu exporto 500 memórias do ChatGPT e importo no Claude, como verifico que nada foi perdido ou corrompido no trânsito? Content hashes e checksums não são opcionais — são essenciais para qualquer formato que se proponha a ser confiável.

Separação entre conversas e memórias. Logs de conversas brutos não são memórias. São a matéria-prima da qual memórias são derivadas. Um bom formato precisa representar ambos: as conversas como aconteceram, e o conhecimento estruturado extraído delas.

Nenhum formato vai acertar tudo na primeira versão. Estes são os requisitos que consideramos mais importantes — e os mais negligenciados pelas abordagens existentes.

Apresentando o PAM: Portable AI Memory

Este é o problema que o Portable AI Memory (PAM) foi projetado para resolver.

O PAM é uma especificação aberta — não um produto, não um serviço, não uma API — que define um formato de intercâmbio vendor-neutral para memórias de IA do usuário. Pense nele como o que o vCard é para contatos, ou o iCalendar é para eventos, mas para o conhecimento que sua IA acumulou sobre você.

A especificação define três JSON Schemas composáveis:

• Memory Store — Memórias estruturadas com tipos, scores de confiança, ciclo de vida temporal, rastreamento de proveniência, referências cruzadas e verificação de integridade. Cada memória carrega um content hash para deduplicação e um tipo semântico de uma taxonomia fechada (fact, preference, skill, context, relationship, goal, instruction, identity, environment, project).

• Conversation — Logs de conversas normalizados com formato de mensagem provider-agnostic, estrutura DAG para conversas com ramificações, tool calls, citações e conteúdo multipart. É aqui que a matéria-prima reside.

• Embeddings — Representações vetoriais vinculadas a memórias específicas, armazenadas inline ou por referência a vector stores externos.

Um bloco de integridade com canonicalização RFC 8785 garante que, quando você exporta 500 memórias e as importa em outro lugar, pode verificar criptograficamente que cada uma chegou intacta.

Veja como uma única memória PAM se parece:

{
  "id": "mem-042",
  "type": "preference",
  "content": "User prefers concise, technical answers without excessive explanation",
  "content_hash": "sha256:a1b2c3...",
  "provenance": {
    "platform": "chatgpt",
    "extraction_method": "llm_inference",
    "conversation_ref": "conv-2025-03-15"
  },
  "temporal": {
    "created_at": "2025-03-15T10:30:00Z",
    "updated_at": "2025-11-20T14:15:00Z"
  },
  "confidence": {
    "current": 0.92,
    "decay_model": "time_exponential"
  },
  "tags": ["communication", "formatting"]
}

Cada campo existe por um motivo. O type diz aos sistemas downstream como aplicar essa memória. O provenance diz o quanto confiar nela. O bloco temporal diz quando foi confirmada pela última vez. O bloco confidence modela como a certeza muda ao longo do tempo. E o content_hash permite verificar integridade após o trânsito.

O que o PAM não faz

O PAM é um formato de arquivo, não uma plataforma. É importante ser claro sobre o que ele não cobre:

Sem sincronização em tempo real. O PAM define um formato de intercâmbio estático — um arquivo .pam.json. Ele não define um protocolo de sync, uma API de streaming, ou um mecanismo de atualização em tempo real. Se você precisa de sync ao vivo entre plataformas, precisa de um produto como MemoryPlugin ou AI Context Flow por cima.

Sem extração de memórias. O PAM não decide o que deve ser uma memória. Converter conversas brutas em memórias estruturadas requer julgamento — geralmente de um LLM. O SDK do PAM fornece converters para exportações de plataformas e uma estrutura para os resultados, mas a inteligência de extração é uma preocupação separada.

Sem aplicação de controle de acesso. O PAM inclui um schema de controle de acesso (níveis de visibilidade, permissões compartilhadas), mas a aplicação é responsabilidade do sistema consumidor. O PAM descreve a política; não a aplica.

Sem geração de embeddings. O schema de embeddings armazena vetores e os vincula a memórias, mas o PAM não gera embeddings. Isso depende de qual modelo e dimensões você escolher.

Essas limitações são deliberadas. Um formato que tenta ser uma plataforma acaba não sendo nenhum dos dois. O PAM fica na sua faixa — definir a estrutura, verificar a integridade, deixar o resto para o ecossistema.

A especificação completa, JSON Schemas, exemplos e um SDK Python estão publicados em portable-ai-memory.org. O SDK inclui converters para exportações das principais plataformas de IA, validação profunda além do JSON Schema (referências cruzadas, consistência temporal, verificação de content hash) e uma CLI para operações rápidas.

A analogia do vCard — e por que importa

Quando o vCard foi introduzido em 1995, cada cliente de e-mail e agenda tinha seu próprio formato proprietário de contatos. Contatos estavam presos no Outlook, no Lotus Notes, nos Palm Pilots. A solução não foi um serviço universal de contatos — foi um arquivo universal de contatos. Um arquivo .vcf que qualquer aplicação podia ler e escrever.

O vCard não precisou de um vcard-outlook-loader ou de um vcard-palm-sync service. O formato era bom o suficiente, e aberto o suficiente, para que cada aplicação implementasse suporte independentemente. O padrão teve sucesso porque era simples, preciso, e não tentava ser um produto.

O PAM segue a mesma filosofia. Ele não compete com Mem0, Cognee ou Letta — ele os alimenta. Exporte do ChatGPT, converta para PAM, importe em qualquer sistema que implemente um loader PAM. A spec é o valor. O SDK facilita a adoção. O resto fica com o ecossistema.

O que acontece agora

O problema da portabilidade de memória IA será resolvido. A única questão é como. Ou as grandes plataformas definirão interoperabilidade nos seus próprios termos (improvável — o incentivo delas é o lock-in), reguladores imporão com requisitos técnicos potencialmente rígidos (possível — a UE já está nessa direção), ou a comunidade de desenvolvedores convergirá em um padrão aberto que torne a portabilidade o comportamento padrão.

O PAM é nossa contribuição para a terceira opção. A especificação está publicada. Os schemas estão validados. O SDK funciona hoje. O que falta agora é adoção — desenvolvedores construindo converters, sistemas de memória aceitando PAM como formato de entrada, e usuários exigindo o direito de serem donos do seu contexto de IA.

Suas memórias de IA são suas. Elas não deveriam estar presas.

---

O PAM é uma especificação aberta publicada sob Creative Commons. O SDK Python é licenciado sob Apache 2.0. Ambos estão disponíveis em portable-ai-memory.org e GitHub.

Daniel Ginês é o criador do PAM e engenheiro DevOps.