Lei DPDP da Índia: Conformidade de WiFi para Visitantes em Estabelecimentos Indianos

Lei DPDP da Índia: Conformidade de WiFi para Visitantes em Estabelecimentos Indianos Um Informativo Técnico da Purple - Aproximadamente 10 Minutos [INTRODUÇÃO E CONTEXTO - 1 minuto] Boas-vindas ao Informativo Técnico da Purple. Sou o seu anfitrião e hoje vamos mergulhar em algo que deve estar no radar de todo diretor de TI e líder de conformidade agora mesmo: a Lei de Proteção de Dados Pessoais Digitais da Índia - a Lei DPDP - e o que ela significa especificamente para implantações de WiFi para visitantes em estabelecimentos indianos. Quer você gerencie uma rede de hotéis em Mumbai, propriedades de varejo em Bengaluru, um estádio em Hyderabad ou a filial indiana de uma multinacional - se você opera WiFi para visitantes e captura dados de cadastro por meio de um Captive Portal, esta legislação afeta você diretamente. As regras estão em vigor, a fiscalização está aumentando e as penalidades são substanciais. Estamos falando de até duzentos e cinquenta crore de rúpias apenas para falhas de segurança. Então vamos começar. Nos próximos dez minutos, vou guiar você pelas principais obrigações, mostrar como isso difere do GDPR na prática, apresentar uma estrutura prática de retenção e apontar os três erros mais comuns que os estabelecimentos estão cometendo agora. [APROFUNDAMENTO TÉCNICO - 5 minutos] Vamos começar com os fundamentos. A Lei de Proteção de Dados Pessoais Digitais foi promulgada em agosto de 2023, com as regras de implementação finalizadas no final de 2025. Os cronogramas de conformidade estão ocorrendo em uma base faseada de doze a dezoito meses a partir do momento em que as regras entraram em vigor - portanto, se você ainda não iniciou seu programa de conformidade, já está atrasado. A primeira coisa a entender é a terminologia. De acordo com a Lei DPDP, seu estabelecimento é o Fiduciário de Dados - você decide o porquê e como os dados pessoais são processados. O provedor da sua plataforma de WiFi - seja a Purple ou qualquer outro fornecedor - é o Processador de Dados. E seu visitante é o Titular dos Dados. Essa distinção é extremamente importante porque, sob a DPDP, ao contrário do GDPR, toda a responsabilidade de conformidade cabe ao Fiduciário de Dados. O DPA do seu provedor de plataforma não transfere o seu risco. Ele é seu. Agora, o consentimento. É aqui que a maioria dos estabelecimentos se perde. A Seção 6 da Lei exige que o consentimento seja livre, específico, informado, incondicional e inequívoco, com uma ação afirmativa clara. Essa palavra "incondicional" é exclusiva da DPDP - não está no GDPR - e tem força real. Isso significa que você não pode fazer do consentimento de marketing uma condição para receber acesso ao WiFi. Ponto final. Como isso se parece na prática em um Captive Portal? Você precisa de três coisas. Primeiro, um aviso em conformidade com a DPDP exibido antes que qualquer dado seja coletado - ele deve indicar quais dados você está coletando, por quê, por quanto tempo os manterá, como o visitante pode retirar o consentimento e como ele pode entrar em contato com o seu Encarregado de Proteção de Dados ou pessoa responsável designada. Segundo, caixas de seleção de consentimento granulares: uma para acesso à rede - que é o processamento necessário - e caixas de seleção separadas e opcionais para comunicações de marketing e análises ou criação de perfil. Estas devem estar desmarcadas por padrão. Terceiro, você deve registrar o consentimento - carimbo de data/hora, endereço IP, versão do consentimento e exatamente o que foi acordado - e você deve ser capaz de apresentar esse registro mediante solicitação. Uma observação prática sobre a mecânica do Captive Portal: se você estiver implantando em dispositivos Apple iOS, Android ou máquinas Windows, o Captive Network Assistant - ou CNA - se comporta de maneira diferente em cada plataforma. O CNA da Apple abre um mini-navegador que possui limitações em relação a cookies e redirecionamentos. Você precisa garantir que seu mecanismo de consentimento funcione dentro dessas restrições. O guia da Purple sobre detecção de Captive Portal aborda a implementação técnica em detalhes - vale a pena lê-lo junto com este informativo de conformidade. Agora vamos falar sobre retenção de dados, porque é aqui que vejo a maior confusão. A abordagem da Lei DPDP é orientada por propósitos. De acordo com a Seção 8(7), você deve apagar os dados pessoais quando o Titular dos Dados retirar o consentimento ou quando a finalidade especificada não estiver mais sendo atendida - o que ocorrer primeiro. A Regra 8 adiciona duas sobreposições importantes. Primeiro, para certas plataformas de alto volume - comércio eletrônico com mais de duas dezenas de milhões de usuários, mídias sociais, jogos online - o Terceiro Cronograma estabelece um período de cessação presumido de três anos. Se não houver interação por três anos, considera-se que a finalidade não está mais sendo atendida. Para a maioria dos operadores de locais - hotéis, varejo, estádios - você não se enquadrará nessas categorias específicas do Terceiro Cronograma, portanto, aplica o princípio geral da Seção 8(8): se o visitante não interagiu com você ou não exerceu seus direitos por um período razoável, você deve apagar os dados dele. Segundo, a Regra 8(3) cria um piso mínimo: você deve reter os logs de processamento e dados associados por pelo menos um ano a partir da data de processamento, independentemente da cessação da finalidade. Isso serve para fins de auditoria e regulatórios. Portanto, para uma política de retenção prática para locais, aqui está a estrutura que eu recomendaria: reter perfis ativos de WiFi de visitantes pela duração do relacionamento mais um ano. Se um visitante não se conectar ou não engajar por vinte e quatro meses, acione um fluxo de trabalho de novo consentimento ou exclusão. Mantenha os logs de processamento por no mínimo um ano. Para hóspedes de hotéis, a estadia cria uma relação de processamento legítima - mas o marketing pós-estadia exige consentimento separado, e esse consentimento tem seu próprio cronômetro de retenção. Agora, transferências transfronteiriças de dados. Isso é realmente mais simples sob a DPDP do que sob o GDPR. A Lei usa uma abordagem de lista negra - as transferências são permitidas para todos os países, a menos que o Governo Central restrinja especificamente um determinado país ou território por meio de notificação. Contraste isso com a abordagem de lista de permissões do GDPR, onde você precisa de uma decisão de adequação, Cláusulas Contratuais Padrão ou Regras Corporativas Vinculativas para cada transferência para um país sem nível de adequação. Para locais multinacionais que usam plataformas de WiFi baseadas em nuvem com data centers fora da Índia, você atualmente tem mais flexibilidade sob a DPDP - mas fique atento, pois os poderes de notificação do Governo significam que o cenário pode mudar. Deixe-me também cobrir os direitos que seus visitantes têm sob a DPDP, porque suas equipes de TI e operações precisam ser capazes de responder a eles. Os Titulares de Dados têm o direito de acessar informações sobre seu processamento, o direito de correção e exclusão, e o direito a reparação de queixas - com uma janela de resposta obrigatória de noventa dias. O que eles não têm, ao contrário do GDPR, é o direito à portabilidade de dados, o direito de se opor à tomada de decisões automatizadas ou o direito à restrição do processamento. Esse é um arcabouço de direitos mais restrito, o que simplifica um pouco suas obrigações de resposta. Os dados de crianças são uma categoria separada e de maior risco. Sob a DPDP, o consentimento parental verificável é exigido para o processamento de dados de qualquer pessoa menor de dezoito anos. Se o seu WiFi no local estiver em um ambiente familiar - um shopping, um parque temático, um hotel familiar - você precisa de um mecanismo para identificar e lidar com usuários menores de idade. Este é um desafio técnico e operacional complexo que muitos locais ainda não abordaram. [RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ERROS COMUNS - 2 minutos] Deixe-me apresentar os três erros mais comuns que vejo e como evitá-los. Erro número um: consentimento agrupado. Esta é a violação mais frequente. Os locais apresentam uma única caixa de seleção "Aceito os termos e condições" que cobre tanto o acesso à rede quanto o marketing. Sob a Seção 6 da DPDP, isso não está em conformidade. A correção é simples - separe seu consentimento em caixas de seleção distintas e específicas para cada finalidade, e garanta que a de marketing seja opcional e desmarcada por padrão. Erro número dois: falta de trilha de auditoria de consentimento. Se o Conselho de Proteção de Dados solicitar que você demonstre que um visitante específico deu consentimento em uma data específica para uma finalidade específica, você consegue apresentar esse registro? A maioria dos locais não consegue. Sua plataforma de WiFi deve armazenar registros de consentimento com granularidade suficiente - carimbo de data/hora, ID da sessão, endereço IP, versão do consentimento e as finalidades específicas consentidas. A plataforma da Purple captura isso nativamente, mas se você estiver em um sistema legado, essa é uma lacuna que você precisa fechar urgentemente. Armadilha três: ausência de um acordo de processamento de dados. De acordo com a Seção 8(2), você deve ter um contrato válido com qualquer operador de dados que contratar. Se o seu provedor de plataforma WiFi não tiver um Acordo de Processamento de Dados atual que faça referência às obrigações da DPDP, você estará exposto. Isso não é apenas uma formalidade legal - é um pré-requisito para a defesa de conformidade do controlador de dados. Do lado da implementação, a decisão de arquitetura fundamental é onde os dados de consentimento são armazenados e como eles se integram ao seu CRM ou plataforma de automação de marketing. Você precisa de uma única fonte da verdade para o status do consentimento que sua equipe de marketing não possa anular. A revogação do consentimento deve ser propagada para todos os sistemas downstream dentro de um prazo razoável - eu recomendaria um máximo de setenta e duas horas como seu SLA operacional. Para estabelecimentos com várias propriedades - redes de hotéis, redes de varejo - você precisa decidir se o consentimento dado em uma propriedade se estende às outras. Sob o requisito de especificidade da DPDP, a posição mais segura é o consentimento no nível da propriedade, a menos que seu aviso cubra explicitamente o grupo e os hóspedes tenham consentido com o processamento em todo o grupo. [PERGUNTAS E RESPOSTAS RÁPIDAS - 1 minuto] Deixe-me passar por algumas perguntas que recebo regularmente. "Posso usar WiFi analytics - contagem de visitantes, tempo de permanência - sem consentimento?" Se os dados forem genuinamente anonimizados e não puderem ser vinculados a um indivíduo, eles ficam fora do escopo da lei DPDP. Mas a randomização de endereços MAC significa que o rastreamento no nível do dispositivo está cada vez mais não confiável de qualquer maneira. Para análises identificadas, você precisa de consentimento. "Preciso de um Encarregado pelo Tratamento de Dados Pessoais?" Um DPO completo é obrigatório apenas para Controladores de Dados Significativos - uma classificação que o governo notificará. Para a maioria dos operadores de estabelecimentos, você precisa de uma pessoa responsável designada cujos dados de contato sejam publicados. Esse é um patamar mais baixo, mas ainda precisa ser alguém que possa realmente responder a perguntas sobre proteção de dados. "Qual é a exposição a penalidades para uma rede de hotéis de médio porte?" Uma falha de segurança que leve a uma violação acarreta até duzentos e cinquenta crores de rúpias. A falha em notificar o Conselho sobre uma violação é de mais duzentos crores. Esses são limites fixos, não porcentagens do faturamento - o que significa que eles atingem as organizações menores proporcionalmente com mais força do que as penalidades baseadas em faturamento do GDPR atingem as grandes multinacionais. [RESUMO E PRÓXIMOS PASSOS - 1 minuto] Para encerrar, aqui estão suas cinco ações imediatas. Primeira: audite o fluxo de consentimento do seu Captive Portal hoje mesmo. Se ele tiver uma única caixa de seleção ou agrupar marketing com acesso, ele precisa ser reconstruído. Segunda: implemente uma trilha de auditoria de consentimento. Cada evento de consentimento deve ser registrado com carimbo de data/hora, IP, finalidade e versão. Terceira: estabeleça uma política de retenção de dados. Para a maioria dos estabelecimentos, um gatilho de inatividade de vinte e quatro meses para novo consentimento ou exclusão é um ponto de partida razoável, com um mínimo de um ano para logs de processamento. Quarta: revise seus Acordos de Processamento de Dados com seu provedor de plataforma WiFi e quaisquer fornecedores downstream de marketing ou analytics. Cinco: designe uma pessoa responsável por dúvidas de proteção de dados e publique seus detalhes de contato em seu captive portal e website. A DPDP Act não é tão complexa quanto o GDPR em termos de amplitude de obrigações, mas é igualmente séria em termos de intenção de aplicação. O Conselho de Proteção de Dados tem dentes reais, e a estrutura de penalidades é projetada para ser significativa, mesmo para grandes organizações. Para um aprofundamento na arquitetura de captive portal, os guias técnicos da Purple cobrem as especificidades de implementação em detalhes. E se você estiver analisando como a análise de guest WiFi se integra ao seu ecossistema mais amplo de inteligência de locais, a plataforma Purple WiFi Analytics é construída com a captura de dados baseada em consentimento em seu núcleo. Obrigado por ouvir. Até a próxima.