Motor de recomendação não é motor autorizado: a fronteira que decide se a IA da sua loja é ativo ou passivo

Essa fronteira existe porque motores generativos tendem a pedir mais contexto para responder melhor. Preferências, endereço, estoque local, histórico, benefícios de assinatura, limites de crédito, elegibilidade promocional, política de devolução específica, status do pedido. Cada um desses dados melhora a resposta — e cada um deles é uma decisão de privacidade.

O resultado é uma tensão estrutural entre personalização e privacidade que não se resolve no discurso. Se resolve na arquitetura.

Camada 1 — Identidade pública contra identidade privada

O primeiro corte é o mais importante, e ele é conceitualmente simples.

Conteúdo público — destinado a Google, Bing, ChatGPT e mecanismos similares — deve ser, em essência, público, consistente e auditável: catálogo, atributos, mídia, preço público, disponibilidade, política padrão, reputação, reviews e conteúdo editorial.

Conteúdo privado — histórico de pedidos, preços negociados, saldo de pontos, benefícios de assinatura, address book, devoluções individuais, análise de crédito, cartões salvos — só pode entrar no contexto quando o usuário está autenticado, autorizado e coberto por base legal adequada.

O ACP da OpenAI deixa esse modelo explícito no fluxo de compra: o checkout é renderizado na interface do ChatGPT, mas o estado real da compra, o processamento de pagamento e a decisão de aceitar ou recusar o pedido permanecem nos sistemas do merchant, que também avalia risco e fraude na própria stack.

Camada 2 — Autorização contextual

Quando um assistente pergunta internamente "qual o melhor produto para este cliente?", a resposta pode depender de ACLs por tenant, papel, segmento, conta, catálogo restrito, país, operação B2B ou B2C, e indicadores de privacidade.

Em stacks de dados modernos, isso costuma significar três coisas ao mesmo tempo:

• →RLS em banco relacional — o PostgreSQL documenta Row-Level Security como controle por linha.
• →Filtros por tenant e namespace no vetor — a Pinecone recomenda namespaces para isolar tenants; Weaviate e Qdrant oferecem multi-tenancy e tenant indexing.
• →Um policy engine capaz de negar ou redigir campos antes do prompt.

A ordem importa: filtrar antes do prompt, não depois da resposta. Confiar que o modelo vai "escolher não mencionar" um dado que ele recebeu é uma política de esperança, não de segurança.

Isso é especialmente crítico quando o mesmo corpus vetorial serve múltiplas marcas, sellers, CNPJs ou shoppers — situação comum em marketplaces e grupos varejistas.

Camada 3 — Autenticação adaptativa e risco

Aqui o objetivo não é bloquear tudo. É reduzir account takeover e fraudes de alto valor sem destruir conversão. Segurança que derruba receita não é segurança bem calibrada — é custo transferido.

As plataformas de mercado documentam mecanismos maduros: a Microsoft Entra oferece Conditional Access com localizações nomeadas, inclusive GPS em certos cenários, e o Entra ID Protection usa sinais como impossible travel e propriedades incomuns, com aprendizado inicial do comportamento; a Okta documenta behavior detection com device, location, IP, ASN e velocity; o PingOne Protect avalia rede, localização, hardware, configurações do dispositivo e biometria comportamental; e o Duo trabalha com device trust e trusted endpoints.

No e-commerce, isso encaixa em pontos específicos: login, recuperação de conta, mudança de endereço, wallet, crédito, gift card, BOPIS e checkout de alto risco.

Camada 4 — Consentimento e preferência

O uso de identidade para personalização em respostas generativas não pode ser "silencioso por padrão" quando envolve dados pessoais, perfilamento ou categorias sensíveis.

Plataformas de gestão de consentimento como OneTrust, Didomi e Osano existem justamente para coletar, armazenar e sinalizar preferências de consentimento e escolha do titular. Em um e-commerce avançado, esse sinal precisa chegar até o gateway do LLM como um sinal operacional, respondendo a perguntas concretas:

• →Pode usar histórico de navegação?
• →Pode usar compras passadas?
• →Pode usar localização precisa?
• →Pode ativar ajuste de copy e recomendação com first-party data?

Sem isso, o risco de personalização indevida e de inconsistência regulatória sobe muito. E o pior desses riscos não é a multa — é a personalização que expõe, para a pessoa errada, algo que ela não esperava que você soubesse.

Sete princípios de privacidade aplicados

Do ponto de vista regulatório, a combinação de GEO com identidade quase sempre opera sobre dados pessoais. O GDPR explicita que pessoas naturais podem ser associadas a *online identifiers* fornecidos por dispositivos, aplicações e protocolos, e também a *location data*; a orientação do ICO reforça que geolocation data inclui GPS e conexões com Wi-Fi e pode identificar onde alguém vive, trabalha ou circula; a LGPD protege o tratamento de dados pessoais em meio físico ou digital, e a ANPD define o RIPD como instrumento para operações de alto risco; e o regime californiano distingue *precise geolocation* como informação sensível, com regras reforçadas de limitação e salvaguardas.

Isso leva a sete princípios práticos:

O que já se sabe sobre a fronteira seguinte

Duas estratégias de mitigação são particularmente promissoras para o futuro de GEO com privacidade.

On-device inference, hoje fortemente promovida por Apple e Android como caminho para manter dados localmente, com menor latência e mais privacidade.

Privacy-preserving analytics e learning, incluindo differential privacy — abordagem que Apple e Google descrevem como meio de aprender padrões agregados sem reidentificar indivíduos. Para e-commerce, isso é relevante em personalização, aprendizado de preferências, resumo local de intenção e ranking assistido pelo dispositivo.

A tendência mais ampla é o que se pode chamar de privacy-preserving RAG: em vez de mandar todo contexto cru para o modelo central, pipelines com redação automática de PII, retrieval em namespaces por tenant, RLS, differential privacy em analytics agregados e uso de dados sintéticos ou anonimizados para aprendizado de popularidade.

Isso é especialmente atraente para varejo porque o ganho econômico da personalização é alto — mas o custo reputacional de vazamento também é.

As armadilhas nomeadas

O estudo que originou esta série lista o que evitar, e vale reproduzir sem suavizar:

• →Recuperar histórico pessoal, preço privado ou dados de pedido sem verificação de autenticação e consentimento.
• →Usar personalização profunda sem documentação, sem choice architecture e sem trilha de auditoria.
• →Misturar conteúdo público e dados pessoais no mesmo índice, sem isolamento.

As três têm algo em comum: nenhuma delas quebra imediatamente. Todas funcionam bem por meses — até o dia em que não funcionam, e o incidente é público.