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

Esta fronteira existe porque os motores generativos tendem a pedir mais contexto para responderem melhor. Preferências, morada, stock local, histórico, benefícios de subscrição, limites de crédito, elegibilidade promocional, política de devoluções específica, estado da encomenda. Cada um destes 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. Resolve-se na arquitetura.

Camada 1 — Identidade pública contra identidade privada

O primeiro corte é o mais importante, e é conceptualmente simples.

Conteúdo público — destinado a Google, Bing, ChatGPT e motores semelhantes — deve ser, na essência, público, consistente e auditável: catálogo, atributos, multimédia, preço público, disponibilidade, política padrão, reputação, avaliações e conteúdo editorial.

Conteúdo privado — histórico de encomendas, preços negociados, saldo de pontos, benefícios de subscrição, moradas guardadas, devoluções individuais, análise de crédito, cartões guardados — só pode entrar no contexto quando o utilizador está autenticado, autorizado e coberto por fundamento de licitude adequado.

O ACP da OpenAI torna este modelo explícito no fluxo de compra: o checkout é apresentado na interface do ChatGPT, mas o estado real da compra, o processamento de pagamento e a decisão de aceitar ou recusar a encomenda 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 ACL por tenant, papel, segmento, conta, catálogo restrito, país, operação B2B ou B2C, e de indicadores de privacidade.

Em stacks de dados modernas, isto costuma significar três coisas ao mesmo tempo:

• →RLS em base de dados relacional — o PostgreSQL documenta Row-Level Security como controlo ao nível da linha.
• →Filtros por tenant e namespace no vetor — a Pinecone recomenda namespaces para isolar tenants; o Weaviate e o 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 recebeu é uma política de esperança, não de segurança.

Isto é especialmente crítico quando o mesmo corpus vetorial serve várias marcas, sellers, entidades jurídicas ou compradores — situação comum em marketplaces e grupos de retalho.

Camada 3 — Autenticação adaptativa e risco

Aqui o objetivo não é bloquear tudo. É reduzir account takeover e fraude de valor elevado 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, incluindo GPS em certos cenários, e o Entra ID Protection usa sinais como impossible travel e propriedades incomuns, com aprendizagem 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 comércio eletrónico, isto encaixa em pontos específicos: início de sessão, recuperação de conta, alteração de morada, carteira digital, crédito, cartão-presente, BOPIS e checkout de risco elevado.

Camada 4 — Consentimento e preferência

O uso de identidade para personalizar respostas generativas não pode ser "silencioso por omissão" quando envolve dados pessoais, definição de perfis ou categorias especiais de dados.

As plataformas de gestão de consentimento como OneTrust, Didomi e Osano existem precisamente para recolher, armazenar e sinalizar as preferências de consentimento e a escolha do titular. Num comércio eletrónico avançado, esse sinal tem de chegar ao gateway do LLM como sinal operacional, respondendo a perguntas concretas:

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

Sem isto, o risco de personalização indevida e de inconsistência regulamentar sobe muito. E o pior desses riscos não é a coima — é a personalização que expõe, à pessoa errada, algo que ela não esperava que a loja soubesse.

Sete princípios de privacidade aplicados

Do ponto de vista regulamentar, a combinação de GEO com identidade opera quase sempre sobre dados pessoais. O RGPD explicita que as pessoas singulares 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 os dados de geolocalização incluem GPS e ligações Wi-Fi e podem identificar onde alguém vive, trabalha ou circula; e o regime californiano (CCPA/CPRA) distingue *precise geolocation* como informação sensível, com regras reforçadas de limitação e salvaguardas. Em Portugal, a autoridade de controlo é a CNPD, e o alinhamento europeu passa pelas orientações do CEPD (EDPB).

Para tratamentos de risco elevado — e a personalização generativa com dados de conta cabe muitas vezes nessa categoria — o RGPD prevê a AIPD (Avaliação de Impacto sobre a Proteção de Dados) antes de a operação entrar em produção. É o instrumento que obriga a escrever, antes do lançamento, o que o sistema recolhe, com que finalidade, com que salvaguardas e com que risco residual.

Isto 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 do GEO com privacidade.

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

Privacy-preserving analytics e learning, incluindo differential privacy — abordagem que a Apple e a Google descrevem como forma de aprender padrões agregados sem reidentificar indivíduos. Para o comércio eletrónico, isto é relevante em personalização, aprendizagem de preferências, resumo local de intenção e ranking assistido pelo dispositivo.

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

É especialmente atrativo para o retalho porque o ganho económico da personalização é elevado — mas o custo reputacional de uma fuga também é.

As armadilhas nomeadas

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

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

As três têm algo em comum: nenhuma se parte de imediato. Todas funcionam bem durante meses — até ao dia em que deixam de funcionar, e o incidente é público.