Política de Privacidade de directtransfer.ch

0Sobre este documento

Esta é a Política de Privacidade do site institucional directtransfer.ch e dos aplicativos DirectTransfer (passageiro e motorista), operados pela plataforma, incluindo o módulo Cargo B2B. Descreve quais dados pessoais tratamos, para que finalidade, com que fundamento, com quem compartilhamos, por quanto tempo retemos e quais são os seus direitos nos termos da Lei Federal suíça de Proteção de Dados (FADP).

Nota de tradução: os artigos da Lei Federal suíça de Proteção de Dados ("Federal Act on Data Protection", FADP; em alemão *Datenschutzgesetz*, DSG/nDSG; em francês *Loi sur la protection des données*, LPD) citados abaixo baseiam-se na tradução inglesa de cortesia consolidada em 2025-07-07, publicada pela Confederação no Fedlex (SR 235.1). A própria Confederação assinala que essa tradução "is provided for information purposes only and has no legal force"; a versão juridicamente vinculativa é sempre a alemã, a francesa ou a italiana.

1Quem somos e o que este documento cobre

A DirectTransfer é operada pela plataforma ("nós", "a plataforma", "DirectTransfer"), na qualidade de responsável pelo tratamento de dados pessoais na acepção do Art. 5 al. j FADP para as finalidades descritas nesta política.

Identidade: DirectTransfer, uma plataforma de corridas baseada na Suíça. Estado de implementação, com precisão: a razão social, a sede e o número de registro comercial (UID) não são publicados nesta política enquanto não existir inscrição oficial e verificável no registro comercial suíço (Zefix/UID); nenhuma atribuição a uma pessoa jurídica não confirmada é feita em nenhum ponto deste documento.
Contato para assuntos de privacidade: privacidade@directtransfer.ch.
Autoridade de supervisão competente: Autoridade Federal de Proteção de Dados e Transparência (PFPDT/FDPIC), nos termos do Art. 4 FADP.

Esta política aplica-se ao site directtransfer.ch, ao aplicativo do passageiro, ao aplicativo do motorista e ao módulo Cargo B2B, sempre que tratarmos dados pessoais de um titular na acepção do Art. 5 al. b FADP.

1.1O que a DirectTransfer é, e o que não é (reafirmação obrigatória)

Esta cláusula é reiterada porque condiciona diretamente o tratamento dos seus dados: a DirectTransfer é software como serviço (SaaS). A plataforma nunca emprega o motorista: não há vínculo de emprego; o motorista é responsável pelo próprio veículo, seguro e agenda. A plataforma nunca define o valor da corrida: o motorista define o preço; a plataforma não calcula nem preenche a tarifa. A plataforma nunca intermedia financeiramente a corrida: o pagamento da corrida é cem por cento entre passageiro e motorista (P2P), via TWINT, SumUp, dinheiro ou o cartão próprio do motorista; nenhum dado de pagamento da corrida é tratado ou armazenado pela DirectTransfer. Isso é distinto e separado do pagamento da assinatura mensal do motorista à plataforma (seção 4.9), que é outro fluxo de dados. Essa distinção determina, entre outras coisas, quais dados de pagamento existem no nosso sistema e quais nunca existirão.

2Definições relevantes (Art. 5 FADP)

Usamos os termos da lei conforme o Art. 5:

Dados pessoais: qualquer informação relativa a uma pessoa física identificada ou identificável (Art. 5 al. a).
Titular: a pessoa física a quem os dados pessoais se referem (Art. 5 al. b).
Dados pessoais sensíveis: incluem, entre outros, dados biométricos que identificam de forma unívoca uma pessoa física, e dados sobre processos ou sanções administrativas e penais (Art. 5 al. c, itens 4 e 5). Nota aplicada ao nosso caso concreto: o documento de identidade e a carteira de habilitação submetidos pelo motorista no cadastro, e os dados biométricos deles extraídos pelo fornecedor terceiro de verificação de identidade (KYC/IDV), constituem dados pessoais sensíveis nesse sentido no item 4; não são tratados como dados pessoais ordinários, ver seção 7. O extrato de antecedentes criminais do motorista, exigido em alguns cantões, constitui dado pessoal sensível no item 5 (dados sobre processos ou sanções administrativas e penais); ver seções 4.2 e 6.
Tratamento: qualquer operação sobre dados pessoais, incluindo coleta, armazenamento, uso, alteração, divulgação, arquivamento, exclusão ou destruição (Art. 5 al. d).
Violação de dados pessoais: perda, exclusão, destruição, alteração, acesso ou divulgação não autorizados, acidentais ou ilícitos de dados pessoais (Art. 5 al. h).
Responsável: quem determina, sozinho ou em conjunto, a finalidade e os meios do tratamento (a plataforma, para as finalidades descritas aqui) (Art. 5 al. j).
Subcontratante: quem trata dados pessoais por conta do responsável, por exemplo o fornecedor de infraestrutura de armazenamento de imagens ou o fornecedor de verificação de documentos (Art. 5 al. k).

3Princípios que aplicamos (Art. 6 FADP)

Todo o tratamento descrito nesta política segue os princípios do Art. 6 FADP: licitude (§1); boa-fé e proporcionalidade (§2); coleta apenas para uma finalidade específica reconhecível pelo titular, sem tratamento posterior incompatível com essa finalidade (§3); destruição ou anonimização dos dados assim que deixarem de ser necessários para a finalidade do tratamento (§4); exatidão dos dados, com correção ou exclusão do que for incorreto ou incompleto (§5). Quando exigimos o seu consentimento, esse consentimento só é válido se for dado de forma voluntária, para uma ou mais operações de tratamento específicas, com informação adequada (§6); e é exigido de forma explícita para o tratamento de dados pessoais sensíveis (§7 al. a).

Nota metodológica sobre a citação de fundamentos nesta política: a FADP não tem uma lista enumerada de "bases legais" no estilo do Art. 6.º, n.º 1, do RGPD. O regime suíço é: o tratamento é lícito se cumprir os princípios deste Art. 6 (licitude, proporcionalidade, finalidade) e não atingir os direitos da personalidade do titular (Art. 30); quando há potencial afetação dos direitos da personalidade, o tratamento exige fundamento de justificação próprio nos termos do Art. 31, em regra "celebração ou execução de um contrato" no Art. 31 §2 al. a (ver aplicação direta na seção 13). Por isso, cada subseção da seção 4 abaixo ancora a licitude geral no Art. 6 e só invoca o Art. 31 §2 al. a quando há justificação efetiva de uma potencial afetação dos direitos da personalidade decorrente da execução do contrato; a partir desta seção, cada subseção que invoca esse fundamento faz-no por referência curta ("fundamento de justificação: Art. 31 §2 al. a, segundo o critério já estabelecido nesta seção 3"), sem repetir o parágrafo explicativo. Os Art. 16-17 FADP referem-se exclusivamente à transferência internacional de dados (divulgação de dados pessoais no estrangeiro) e são citados só na seção 8, nunca como base geral de tratamento interno, distinção mantida de forma consistente.

Nota sobre "fundamento de justificação": este conceito é próprio do regime suíço do Art. 31 FADP e não tem equivalente direto no vocabulário do RGPD. Deliberadamente não é traduzido aqui como "base legal", porque esse termo carrega outra conotação no RGPD. Usa-se "fundamento de justificação" para preservar essa distinção.

Nota de verificação de fonte, quanto ao "Art. 31 §2 al. a": a existência do fundamento de justificação por execução de contrato no Art. 31 §2 está confirmada pela fonte primária consultada (o registro interno de fontes FADP mantido para esta política, Parte A, "Art. 30-31"), mas essa fonte resume ou parafraseia o conteúdo do artigo, ao contrário dos Art. 5, 6, 8, 19 e 25, que são cópia literal extraída via pdftotext do PDF oficial do Fedlex, sem citar o texto integral e numerado das alíneas do Art. 31 §2. A referência à alínea exata "al. a" nesta política é, por isso, a leitura mais provável e consistente com a estrutura típica deste tipo de norma, não uma citação verbatim confirmada da alínea. A substância do fundamento (execução de contrato como justificação de potencial afetação da personalidade) é usada nesta política com confiança alta; a letra exata da alínea permanece com confiança média, sujeita a confirmação direta contra o texto integral do Art. 31 ou a parecer de advogado suíço licenciado, o mesmo padrão de precaução já aplicado ao Art. 9.

4Quais dados coletamos e para quê

4.1Cadastro de conta

Nome e contato (telefone, e-mail) de passageiro e motorista, no ato de criação da conta. Finalidade: prestar o serviço de intermediação tecnológica entre passageiro e motorista. Fundamento: licitude, proporcionalidade e finalidade reconhecível do tratamento (Art. 6 §1-3): o dado é coletado para o fim específico, reconhecível pelo titular, de criar e operar a conta; fundamento de justificação: Art. 31 §2 al. a, segundo o critério já estabelecido na seção 3.

4.2Verificação documental do motorista (dados sensíveis)

No cadastro do motorista, coletamos documento de identidade, carteira de habilitação e, conforme o cantão e a categoria, outras autorizações (por exemplo carte de taxi, carte de limousine). Onde o cantão exigir (por exemplo Zurique e Basileia, segundo pesquisa regulatória cantonal interna já disponível ao projeto), também coletamos o extrato de antecedentes criminais do motorista, com validade inferior a 3 meses no momento da submissão. Esses documentos são submetidos por foto, segundo o fluxo descrito no módulo de Cadastro do Motorista, e tratados em duas camadas:

Camada 1, fornecedor terceiro (KYC/IDV): confirma a autenticidade do documento e extrai os campos legíveis (nome, número, datas, tipo de documento), incluindo, quando aplicável, verificação biométrica. Este tratamento envolve dados pessoais sensíveis na acepção do Art. 5 al. c item 4 (documento de identidade, carteira de habilitação, dados biométricos) e, quando aplicável ao extrato de antecedentes criminais, item 5 (dados sobre processos ou sanções administrativas e penais), exigindo o seu consentimento explícito (Art. 6 §7 al. a) no ato de submissão do documento, e um contrato de tratamento de dados com o fornecedor. Essa obrigação decorre do tratamento de dados pessoais por um subcontratante por conta do responsável (o Art. 5 al. k FADP define subcontratante nesses termos) e enquadra-se nos princípios gerais de licitude e proporcionalidade do Art. 6 e no dever de segurança do Art. 8. Esta política não cita aqui um número de artigo específico da FADP para a subcontratação além da definição do Art. 5 al. k, por isso não ter sido confirmado contra o texto integral da lei.
Camada 2, motor de regras interno, sem inteligência artificial: verifica se os campos extraídos cumprem a exigência documental do cantão e da categoria declarados. Não usa modelo de IA/ML; é comparação determinística contra uma tabela de configuração.

Um veredito incerto em qualquer das camadas nunca é autoaprovado nem autorrejeitado; vai sempre para revisão humana de um administrador. Os documentos do motorista, incluindo o extrato de antecedentes criminais, são acessíveis apenas pelo próprio motorista e por administradores, nunca pelo passageiro, com o mesmo tratamento reforçado (consentimento explícito, RBAC restrito) descrito na seção 6.

Renovação e verificação contínua: a exigência mínima aplicada é validade inferior a 3 meses do extrato de antecedentes criminais no momento de cada submissão; a submissão inicial não deve ser lida como cobertura para todo o ciclo de vida do motorista. A frequência de renovação exigida e o mecanismo de verificação contínua de antecedentes, quando aplicável por cantão, são comunicados diretamente ao motorista pelo canal de contato do aplicativo, e serão publicados nesta seção assim que a política operacional correspondente for finalizada.

Fornecedor terceiro (KYC/IDV): o nome comercial do fornecedor será publicado nesta seção assim que a seleção for encerrada, segundo o processo de cotação em curso; entretanto, está disponível a pedido pelo canal de contato da seção 15. O contrato de tratamento de dados com esse fornecedor, referido acima, e a avaliação de transferência internacional (seção 8), caso o fornecedor não opere em território suíço ou da UE/EEE, serão concluídos e publicados juntamente com essa identificação, antes de qualquer submissão de documento ser tratada por esse fornecedor em produção.

4.3Localização em tempo real durante a corrida

A localização aproximada dos veículos disponíveis é compartilhada com o passageiro antes da aceitação de uma corrida; depois da aceitação, a posição do motorista é compartilhada com o passageiro até o embarque. Finalidade: execução direta do contrato de transporte acordado entre passageiro e motorista. Fundamento: proporcionalidade e finalidade reconhecível pelo titular no momento do pedido (Art. 6 §2-3), pois pode afetar os direitos da personalidade do titular pela exposição da posição geográfica a um terceiro; fundamento de justificação: Art. 31 §2 al. a, segundo o critério já estabelecido na seção 3.

4.4Foto do ponto de embarque (exclusão automática em 24 horas)

Na comunicação da corrida, uma foto do ponto de embarque pode ser compartilhada entre passageiro e motorista, armazenada no Cloudflare R2.

O desenho de ciclo de vida já congelado do projeto prevê a exclusão automática desta foto 24 horas após o envio, e nenhuma retenção além desse prazo para qualquer finalidade secundária, segundo o desenho interno do esquema de dados do projeto, que fixa essa janela de 24 h como derivada no momento da consulta (created_at + interval '24 hours') para mensagens do tipo photo. Estado de implementação, com precisão: o serviço de backend da plataforma existe e está operacional para o cadastro do motorista, mas o módulo de corrida/chat que executaria essa janela (um job de expurgo em nível de aplicativo e/ou uma regra de ciclo de vida do bucket Cloudflare R2) ainda não foi construído; e, quanto à camada de banco de dados, a ratificação final da política de segurança correspondente pela revisão interna de segurança da plataforma permanece pendente. Até que esse módulo seja construído e essa ratificação esteja completa, as 24 horas descritas aqui são o desenho vinculante do projeto, ainda não um fato operacionalmente verificável em produção.

Finalidade: facilitar o encontro físico entre as partes. Fundamento: execução do contrato e proporcionalidade (Art. 6 §2-3); a exclusão automática em 24 horas desenhada acima é a aplicação concreta do dever de destruição do Art. 6 §4 assim que o dado deixa de ser necessário para a finalidade, pois o encontro já ocorreu; fundamento de justificação: Art. 31 §2 al. a, segundo o critério já estabelecido na seção 3.

4.5Mensagens de chat da corrida (`ride_messages`)

Durante uma corrida ativa, passageiro e motorista podem trocar mensagens predefinidas, texto livre limitado (até 100 caracteres) ou uma foto, pelo chat da corrida. Finalidade: comunicação direta entre as partes durante a corrida ativa, por exemplo instruções de embarque ou ajuste do ponto de encontro, enquanto a corrida está em andamento.

Retenção: a regra de ciclo de vida desenhada é a exclusão efetiva (hard delete) do conteúdo do chat quando a corrida é encerrada, uma decisão de desenho já fechada do projeto quanto ao critério, não uma lacuna. Segundo a revisão interna de segurança e conformidade da plataforma, isto é a aplicação direta do mandamento "Zero chat após o fim da corrida", e essa regra está registrada de forma explícita no desenho interno do esquema de dados do projeto. Estado de implementação, com precisão: esse desenho de esquema atribui expressamente o job de expurgo ao serviço de backend da plataforma; o serviço de backend agora existe e está operacional para o cadastro do motorista, mas o módulo de corrida/chat que executaria esse job específico ainda não foi construído; a política de segurança correspondente em nível de banco de dados permanece registrada apenas como rascunho interno, explicitamente marcada "STUB, NOT RATIFIED", pendente de ratificação final pela revisão interna de segurança da plataforma. Até que esse módulo seja construído e essa ratificação esteja completa, a remoção efetiva (hard delete, não soft-delete, sem flag "deleted") é o desenho vinculante do projeto, ainda não um fato operacionalmente verificável em produção.

Fundamento: execução do contrato de transporte entre as partes e segurança da coordenação da corrida em curso (Art. 6 §2-3); a exclusão automática no encerramento da corrida, desenhada acima, é a aplicação concreta do dever de destruição do Art. 6 §4 assim que o dado deixa de ser necessário para a finalidade, pois a corrida já terminou; fundamento de justificação: Art. 31 §2 al. a, segundo o critério já estabelecido na seção 3.

Nenhuma mensagem de chat é lida, moderada ou retida pela DirectTransfer além do necessário para a operação técnica em tempo real da própria corrida; qualquer leitura pontual por um administrador a investigar uma reclamação formal segue o mesmo padrão auditado de acesso privilegiado descrito na seção 12.

Metadados de denúncia de abuso (em avaliação, não implementado): um registro mínimo de metadados de denúncia de abuso (não o conteúdo da mensagem) está em avaliação, pendente de citação jurídica antes de qualquer implementação, segundo a revisão interna de segurança e conformidade da plataforma; se for implementado, esta seção será atualizada.

4.6Comunicação por chamada telefônica (chamada GSM nativa, sem VoIP)

A plataforma disponibiliza um botão de chamada que usa a função nativa de chamada GSM do celular de cada usuário. Não há sistema VoIP, WebRTC nem intermediação de chamada pela DirectTransfer de espécie alguma: a chamada corre inteiramente pela operadora de cada parte, fora da nossa infraestrutura.

Divulgação relevante para o seu consentimento informado: ao usar este botão, o número de telefone de cada parte pode tornar-se visível à outra no momento da chamada, porque a rede GSM nativa entrega o número real de origem/destino às duas partes pela própria natureza do protocolo; essa exposição não pode ser evitada mantendo o botão de chamada nativa, segundo a avaliação técnica registrada pela revisão interna de segurança e conformidade da plataforma.

O que não existe: nenhum número proxy na rede substitui o seu número real durante a chamada; não há proxy/relay telefônico verdadeiro; entre outras razões, um relay desse tipo colidiria com o veto "Zero VoIP" já fixado para este produto.

O que existe: o aplicativo nunca exibe o seu número, nem o da outra parte, como texto em nenhuma tela dos aplicativos passenger ou driver; o número aparece exclusivamente como botão de ação; e o aplicativo pede confirmação explícita antes de acionar o discador nativo (um aviso de que o número ficará visível à outra parte se continuar). Essas duas mitigações são comportamento padrão nos aplicativos.

Nota sobre ocultação de identificação de chamada (CLIR): quando disponível, a ocultação do número de origem via código nativo da rede (por exemplo prefixo #31#/*31#) depende inteiramente da operadora de cada usuário; a plataforma não verifica, não impõe nem garante essa ocultação antes de acionar o discador nativo. Isto não é uma mitigação garantida pelo produto; está registrado como item de investigação de viabilidade por operadora, ainda não concluído, segundo a revisão interna de segurança e conformidade da plataforma.

Nota secundária: o mascaramento de tela descrito acima não cobre o back office admin, que já tem acesso de leitura em texto claro ao número de telefone via RBAC na tabela users (seções 6 e 12), para fins de suporte; esse acesso privilegiado gera obrigatoriamente um registro de auditoria (quem, quando, por quê); não é uma exceção silenciosa à mitigação de tela.

Não gravamos, não armazenamos nem temos acesso a qualquer conteúdo dessa chamada, porque ela nunca passa pela nossa infraestrutura.

Fundamento: o dever de informação e transparência do Art. 19 §2 al. c FADP, que exige informar o titular, no momento da coleta, sobre "os destinatários ou categorias de destinatários a quem os dados pessoais são divulgados" (texto verbatim, segundo o registro interno de fontes jurídicas mantido para esta política); este é o encaixe específico correto para este cenário, identificado pela revisão interna de segurança e conformidade da plataforma: a outra parte da corrida é o destinatário a quem o número de telefone se torna visível no momento da chamada, o que é precisamente uma divulgação a um destinatário, não a extensão genérica do §1 do mesmo artigo (informar sobre dados não coletados junto ao próprio titular) usada numa versão anterior deste texto; essa exposição é divulgada de antemão por esta cláusula, juntamente com a proporcionalidade do tratamento (Art. 6 §2), para permitir o encontro físico e a comunicação durante a corrida. Fundamento de justificação da própria divulgação: Art. 31 §2 al. a, segundo o critério já estabelecido na seção 3; esse fundamento não é afetado pela reancoragem acima, que diz respeito apenas ao componente de dever de informação/transparência. Esse dever de informação é cumprido pela divulgação explícita acima e pelo diálogo de confirmação obrigatório antes de acionar o discador nativo. Este é o fundamento apresentado por esta política para esta cláusula; ver o estado de confirmação no parágrafo seguinte.

Estado de implementação, com a mesma disciplina de precisão usada em toda esta política: o comportamento descrito acima (mascaramento de tela, diálogo de confirmação) é o desenho vinculante já congelado do projeto para os aplicativos passenger e driver. O bloqueio de ativação deste fluxo em produção, segundo a revisão interna de segurança e conformidade da plataforma, não depende do serviço de backend da plataforma (este fluxo, ao contrário dos das seções 4.4, 4.5, 4.7, 6 e 12, nunca passa pela nossa infraestrutura, como descrito acima); depende da confirmação de suficiência jurídica pela revisão interna de segurança e conformidade da plataforma quanto a se o enquadramento Art. 19 §2 al. c + Art. 6 §2 acima cobre de forma adequada, em termos de proporcionalidade, este cenário específico. A reancoragem da citação para o Art. 19 §2 al. c, aplicada acima, corrige o encaixe antes descrito como incerto nesta política: a exposição do número de uma parte à outra durante a chamada é uma divulgação a um destinatário no momento da chamada, e é exatamente este cenário, o dever de informar sobre "os destinatários... a quem os dados pessoais são divulgados", que o Art. 19 §2 al. c cobre no seu texto verbatim, já não a extensão genérica do §1 usada numa versão anterior. Esta política apresenta o Art. 19 §2 al. c + Art. 6 §2 como fundamento da divulgação já feita acima; a suficiência desse enquadramento face ao teste de proporcionalidade do Art. 6 §2 neste cenário específico (por exemplo, se a ausência de um opt-out da funcionalidade ou de uma garantia de CLIR afeta essa suficiência) permanece uma confirmação técnico-jurídica para a revisão interna de segurança e conformidade da plataforma, não um fato já fechado pela equipe jurídica interna sozinha. Nota de coordenação entre documentos: esta posição é a desta Política de Privacidade em concreto; a cláusula paralela sobre o mesmo tema nos Termos de Uso segue o seu próprio ciclo de atualização e permanece marcada naquele documento como pendente de citação; os dois documentos ainda não convergem, e esta nota evita a aparência de que já convergem.

4.7Histórico da corrida e identificador anonimizado (modelo em duas fases)

Por corrida, registramos: origem e destino (coordenadas e endereço em texto), carimbo de início e fim, categoria do veículo, valor declarado pelo motorista, estado final da corrida, e um identificador de passageiro e de motorista. Nenhum outro dado é registrado por omissão.

Este identificador opera em duas fases distintas, não numa única fase:

1. Durante a corrida ativa: o identificador é resolúvel (uma referência direta ao registro do usuário), necessário para a funcionalidade em tempo real: controle de acesso em nível de linha (RLS), a conexão em tempo real (Socket.io) e o chat da corrida em curso (seção 4.5).

2. Na transição para o histórico, quando a corrida termina, o identificador é convertido num hash criptográfico irreversível e com salt (por exemplo SHA-256), sem chave estrangeira que permita rastrear a identidade do usuário a partir do registro histórico.

A regra por omissão, tal como desenhada, segundo o Mandamento 5 (Row Level Security) e segundo os requisitos de RLS já especificados pela revisão interna de segurança e conformidade da plataforma, é a não identificação nominal recíproca entre as partes: nem o passageiro deve ver o nome do motorista, nem o motorista o nome do passageiro, em nenhuma tela, incluindo o histórico. Estado de implementação, com precisão: esta regra está desenhada e refletida no modelo em duas fases descrito acima (identificador resolúvel durante a corrida, hash irreversível na transição para o histórico), mas o mecanismo executável de aplicação (políticas concretas de segurança em nível de banco de dados e a camada de mascaramento de coluna que impede a fuga de identidade mesmo quando a linha é visível) depende da ratificação técnica final pela revisão interna de segurança da plataforma. Correção, 2026-08-23: o serviço de backend da plataforma agora cobre tanto o cadastro do motorista como os fluxos de pedido de corrida/leilão (os fluxos em que este identificador é usado enquanto a corrida está ativa), não só o cadastro do motorista; o que permanece pendente é especificamente a ratificação de RLS acima, não a existência do backend. A política de segurança correspondente em nível de banco de dados permanece marcada "STUB, NOT RATIFIED" no rascunho interno. Esta seção não afirma a não identificação nominal como fato operacional já ativo em produção, apenas como regra de desenho já congelada, pendente de aplicação técnica ratificada.

Identificação por razões de segurança (em avaliação, não decidido): ainda está em avaliação se, por razões de segurança, uma identificação ocasional entre motorista e passageiro (ou vice-versa) poderia tornar-se necessária, o que criaria tensão com a regra geral de não identificação nominal já congelada acima, segundo a documentação interna de produto do projeto para o histórico de corridas. Esta política não afirma, nesta versão, nem a identificação nem a sua ausência total como exceção de segurança; afirma apenas a regra geral de não identificação recíproca já congelada, aplicável enquanto esta avaliação não for concluída. Qualquer resolução futura deste ponto é registrada nesta seção e confirmada pela revisão interna de segurança da plataforma como compatível, ou não, com o RLS já congelado, sem reabertura informal.

Fundamento da anonimização: a transição para o histórico é a aplicação direta do dever do Art. 6 §4: o dado é anonimizado assim que deixa de ser necessário, em forma identificável, para a finalidade de operar a corrida em curso.

4.8Avaliação da plataforma (0 a 5 estrelas)

No fim de cada corrida, o passageiro pode avaliar a plataforma, não o motorista individual. Essa avaliação está ligada ao identificador anonimizado do passageiro e ao evento da corrida, para fins de métrica de produto da empresa. Nunca é agregada, exibida ou consultável por identificador de motorista, nunca aparece em nenhuma tela ou API acessível ao motorista, e nunca é usada para alocar uma corrida. Fundamento: interesse legítimo e proporcional em medir a satisfação com o serviço prestado pela plataforma (Art. 6 §2), sem finalidade de gerir ou avaliar o desempenho individual do motorista; essa distinção de finalidade é precisamente a razão pela qual esta avaliação não circula até o motorista.

4.9Pagamentos: corrida (P2P) e assinatura (Stripe), fluxos separados

Segundo a referência na seção 1.1: o pagamento da corrida é cem por cento entre as partes, fora da nossa infraestrutura, e não tratamos nem armazenamos nenhum dado de pagamento da corrida. O único fluxo de pagamento que tratamos é a assinatura mensal do motorista à plataforma, através do processador de pagamentos Stripe (Stripe Billing), que trata a faturação e os dados de cartão do motorista diretamente, nos termos e na política de privacidade da própria Stripe. Fundamento: proporcionalidade e finalidade do tratamento (Art. 6 §2-3), execução do contrato de assinatura entre o motorista e a plataforma; fundamento de justificação: Art. 31 §2 al. a, segundo o critério já estabelecido na seção 3.

4.10Módulo Cargo B2B e fluxos potencialmente transfronteiriços

O módulo Cargo B2B pode envolver clientes e transportadores situados na União Europeia. Ver a seção 10 sobre o regime jurídico aplicável a este caso.

4.11Site institucional, cookies e analytics

O inventário final de cookies e tecnologias de rastreamento do site institucional directtransfer.ch será publicado nesta seção, com referência a uma política de cookies dedicada se a complexidade o justificar, antes da ativação de qualquer cookie que não seja estritamente necessário ao funcionamento técnico do site. Até essa publicação, o site institucional não ativa nenhum cookie de analytics ou marketing de terceiros sem que esse inventário seja primeiro descrito aqui e, quando aplicável, sem o consentimento prévio exigido pelo Art. 6 §6-7 FADP.

4.12Segurança, prevenção de fraude e cumprimento legal

Podemos tratar dados pessoais para detectar e prevenir fraude, e para cumprir uma obrigação legal ou responder a um pedido legítimo de uma autoridade competente. Fundamento: licitude e proporcionalidade do tratamento (Art. 6 §1-2), enquadrado no cumprimento de uma obrigação legal a que a plataforma está sujeita. Quando este tratamento constituir uma potencial afetação dos direitos da personalidade do titular, o fundamento de justificação aplicável decorre do Art. 31 §2, nas suas alíneas relativas ao cumprimento de uma obrigação legal ou à salvaguarda de um interesse preponderante, categorias gerais da norma, distintas da al. a (execução de contrato) usada noutras subseções desta política; a alínea exata aplicável a cada situação concreta é identificada caso a caso no momento do tratamento.

5Fundamento, em síntese

Tratamos os seus dados pessoais com base, conforme o caso, em: o seu consentimento explícito, exigido em particular para dados sensíveis (Art. 6 §6-7 al. a); a execução do contrato de uso da plataforma ou do contrato de transporte entre você e a outra parte da corrida, fundamento de justificação nos termos do Art. 31 §2 al. a quando há potencial afetação dos direitos da personalidade; o cumprimento de uma obrigação legal a que a plataforma está sujeita; e o interesse legítimo, sempre sujeito ao teste de proporcionalidade do Art. 6 §2. Quando uma finalidade específica exigir consentimento explícito adicional (por exemplo, dados documentais sensíveis do motorista, seção 4.2), pedimos esse consentimento em separado, com registro de auditoria segundo a seção 16.

6Dados pessoais sensíveis: tratamento reforçado

Reiterando a seção 4.2: o documento de identidade, a carteira de habilitação e os dados biométricos associados do motorista são dados pessoais sensíveis (Art. 5 al. c item 4). O extrato de antecedentes criminais do motorista, exigido em alguns cantões (por exemplo Zurique e Basileia, segundo pesquisa regulatória cantonal interna já disponível ao projeto) é igualmente dado pessoal sensível, enquadrado no item 5 do mesmo artigo (dados sobre processos ou sanções administrativas e penais), e recebe o mesmo tratamento reforçado abaixo. Aplicamos, a ambas as categorias, segundo o desenho já congelado do projeto: (i) consentimento explícito no momento da submissão (Art. 6 §7 al. a); (ii) acesso restrito via controle de acesso baseado em papéis (RBAC), limitado ao próprio motorista e a administradores, nunca ao passageiro, incluindo o extrato de antecedentes criminais, segundo a matriz RBAC já especificada pela revisão interna de segurança e conformidade da plataforma. O próprio controle RBAC está construído, testado e operacional no serviço de backend da plataforma para o acesso aos documentos do motorista; a segurança em nível de linha do banco de dados (RLS) sobre os dados subjacentes, como segunda camada complementar de aplicação descrita na seção 4.7 acima, permanece pendente de ratificação final pela revisão interna de segurança da plataforma e ainda está marcada "STUB, NOT RATIFIED" no rascunho interno; (iii) delegação da autenticidade e extração do documento a um fornecedor terceiro estabelecido, sob contrato de tratamento de dados, obrigação decorrente do tratamento de dados pessoais por um subcontratante por conta do responsável (Art. 5 al. k FADP), enquadrada nos princípios gerais dos Art. 6 e 8, sem citar aqui um número de artigo de subcontratação além dessa definição, por isso não ter sido confirmado contra o texto integral da lei; (iv) nenhum motor de reconhecimento facial biométrico construído internamente pela plataforma.

7Com quem compartilhamos dados

Compartilhamos dados pessoais, na medida necessária a cada finalidade descrita na seção 4, com:

Fornecedor terceiro de verificação de identidade e documentos (KYC/IDV), para a verificação documental do motorista, incluindo o extrato de antecedentes criminais quando aplicável (seção 4.2). Nome comercial a publicar nesta seção assim que a seleção for encerrada; entretanto, disponível a pedido pelo canal de contato da seção 15.
Stripe, para o tratamento da assinatura mensal do motorista (seção 4.9), nunca para o pagamento da corrida.
Cloudflare, como fornecedor de infraestrutura de armazenamento (R2) da foto do ponto de embarque (seção 4.4).
A autoridade cantonal competente, quando exigido para validar a autorização de transporte do motorista, ou por obrigação legal.
A autoridade de supervisão (PFPDT/FDPIC) ou outra autoridade competente, quando a lei o exigir.

Não vendemos dados pessoais a terceiros. Não compartilhamos dados identificáveis de corrida para fins de publicidade de terceiros.

8Transferência internacional de dados (Art. 16-17 FADP)

Qualquer subcontratante situado fora da Suíça que produza um efeito sobre um usuário na Suíça está sujeito à FADP em virtude do seu âmbito territorial (Art. 3 §1). Quando um dos nossos fornecedores (por exemplo o fornecedor KYC/IDV, ou a Stripe, conforme a jurisdição do tratamento) estiver estabelecido fora da Suíça e sem decisão de adequação do Conselho Federal (Art. 16 §1), a transferência assenta numa das bases do Art. 16 §2: cláusulas contratuais-tipo aprovadas pela PFPDT (al. d), cláusulas contratuais de proteção de dados notificadas previamente à mesma autoridade (al. b), ou outra base equivalente nos termos da norma; em alternativa, nas exceções do Art. 17 §1, nomeadamente o consentimento explícito (al. a) ou a conexão direta com um contrato (al. b).

Nota de verificação de fonte, sobre as alíneas citadas do Art. 16 §2 e do Art. 17 §1 acima: como já notado na seção 3 relativamente ao Art. 31 §2 al. a, o registro interno de fontes jurídicas compilado para esta política (Parte A, "Art. 16-17") apresenta essas alíneas por resumo/paráfrase do compilador ("verbatim, summarised to the operative letters", no próprio texto da fonte), e não por transcrição literal e numerada do texto integral dos dois artigos, ao contrário dos Art. 5, 6, 8, 19 e 25, citados nesta política a partir de cópia literal extraída via pdftotext do PDF oficial do Fedlex. A existência dos quatro mecanismos citados acima (cláusulas contratuais-tipo aprovadas pela PFPDT, cláusulas contratuais notificadas previamente à mesma autoridade, consentimento explícito, conexão direta com um contrato) é usada nesta política com confiança alta; a letra exata de cada alínea (al. b e al. d do Art. 16 §2; al. a e al. b do Art. 17 §1) permanece com confiança média, sujeita a confirmação direta contra o texto integral dos Art. 16 e 17 no Fedlex ou a parecer de advogado suíço licenciado, o mesmo padrão de precaução já aplicado ao Art. 31 §2 al. a (seção 3) e ao Art. 9.

A base específica dos Art. 16/17 aplicável a cada fornecedor concreto (KYC/IDV, Stripe, conforme a jurisdição efetiva do tratamento) é determinada e publicada nesta seção, por fornecedor, antes de qualquer transferência de dados pessoais começar para esse fornecedor. Nenhuma transferência internacional de dados pessoais ocorre sem que a base aplicável do Art. 16 §2 ou a exceção do Art. 17 §1 esteja identificada e registrada aqui.

9Retenção de dados: critério, segundo o Art. 25 §2 al. d FADP

Segundo o Art. 6 §4 FADP, destruímos ou anonimizamos os dados pessoais assim que deixarem de ser necessários para a finalidade do tratamento. O Art. 25 §2 al. d FADP exige que informemos o titular sobre "o prazo de retenção... ou, se isso não for possível, os critérios para determinar esse prazo"; a lei aceita expressamente o critério como alternativa válida a um número fixo, e esta é a posição desta política.

Critério aplicado, por categoria de dados:

Dados identificáveis da corrida: necessários durante o ciclo de vida operacional da corrida (seção 4.7, fase 1); no encerramento da corrida, os dados transitam para um histórico anonimizado via hash irreversível (seção 4.7, fase 2); a partir desse momento, já não existem em forma identificável.
Foto do ponto de embarque: desenho de exclusão automática 24 horas após o envio (seção 4.4); mecanismo executável pendente da construção do módulo de corrida/chat e da ratificação de RLS, segundo a nota dessa seção.
Mensagens de chat da corrida: exclusão efetiva (hard delete) quando a corrida é encerrada; critério já decidido, mecanismo executável pendente segundo a nota da seção 4.5.
Documento do motorista: retido enquanto a autorização de transporte permanecer ativa; este componente é o desenho já congelado, aplicável desde já. Estado de implementação, com precisão: esta política propõe adicionalmente um prazo de retenção pós-desativação derivado de uma obrigação legal cantonal aplicável ao cantão de cadastro do motorista; essa obrigação cantonal específica ainda não foi identificada por nenhuma fonte primária do projeto; a própria seção 4.2 já reconhece esta lacuna quanto à frequência de renovação e à verificação contínua de antecedentes. Ao contrário dos três critérios precedentes (corrida, foto, chat), que são desenho de arquitetura já congelado e verificável no esquema, este quarto critério permanece parcialmente aberto: "retido enquanto a autorização permanecer ativa" aplica-se desde já; o prazo adicional devido a uma obrigação legal cantonal só pode ser aplicado a partir do momento em que essa obrigação for identificada e citada por uma fonte primária ou parecer jurídico.

Esta é a posição desta política sobre retenção: um critério, segundo o Art. 25 §2 al. d, aplicado a cada categoria de dados descrita nesta política, sem um único prazo numérico para todas as categorias, porque nenhuma delas exige o mesmo prazo, e a lei permite expressamente esta forma de resposta. Três das quatro categorias acima (corrida, foto, chat) têm um critério plenamente fechado, ancorado em desenho de arquitetura já congelado. A quarta (documento do motorista) tem o seu componente principal, retenção enquanto a autorização permanecer ativa, igualmente fechado, com o componente adicional de prazo cantonal ainda aberto, segundo a nota específica desse item acima; esta política será atualizada assim que essa obrigação cantonal for identificada por uma fonte primária.

10FADP e RGPD: divulgação dual

Esta política aplica-se, em regra, nos termos da Lei Federal suíça de Proteção de Dados (FADP/LPD/nDSG), que se aplica a qualquer circunstância com efeito na Suíça, mesmo que iniciada no estrangeiro (Art. 3 §1).

O módulo Cargo B2B (seção 4.10) pode envolver clientes ou transportadores situados na União Europeia. Posição operacional final desta política: quando o cliente ou o transportador do módulo Cargo estiver estabelecido na União Europeia/Espaço Econômico Europeu, ou quando o tratamento visar oferecer um serviço a, ou monitorizar o comportamento de, um titular na UE, a DirectTransfer aplica de forma cumulativa, a esses fluxos específicos, o padrão mais protetor entre a FADP e o Regulamento Geral sobre a Proteção de Dados (RGPD), como política preventiva de conformidade, não como reconhecimento jurídico definitivo da aplicabilidade estrita do RGPD à DirectTransfer. Isso inclui, no mínimo, disponibilizar ao titular na UE os mecanismos de acesso, portabilidade e exclusão já descritos na seção 13, mesmo quando a FADP isoladamente exigiria menos. Um parecer jurídico formal sobre o âmbito exato da aplicabilidade estrita do RGPD a esses fluxos será obtido antes do lançamento comercial transfronteiriço do módulo Cargo; esta política será atualizada com a base jurídica específica do RGPD por finalidade, incluindo, se necessário, a nomeação de um representante na UE, assim que esse parecer estiver disponível.

Uma distinção necessária, ainda não avaliada: qualquer obrigação de nomear um representante na União Europeia (Art. 27 RGPD), se aplicável, é uma obrigação estrutural distinta de "aplicar o padrão mais protetor de direitos" descrito acima; a primeira exige um ponto de contato formal estabelecido na UE, não apenas replicar mecanismos de acesso, portabilidade e exclusão. Esta política não avalia, nesta versão, se essa obrigação estrutural se aplica; essa avaliação depende do mesmo parecer jurídico formal já referido acima.

11Legislação cantonal aplicável

Além da FADP federal, o cadastro e a operação do motorista estão sujeitos à legislação cantonal de transporte (por exemplo, LTVTC em Genebra, regulamento 740.25 em Vaud, LMob Art. 197 em Friburgo), com exigência de autorização própria de "diffuseur de course" (categoria genebrina de licença de despacho/corretagem de corridas no direito cantonal de transporte) em certos cantões, independentemente do estatuto de emprego do motorista. Esta política trata apenas do tratamento de dados pessoais; a base regulatória de transporte está descrita nos documentos internos de conformidade do projeto, não duplicada aqui.

Âmbito geográfico efetivo desta política: o regime de retenção e tratamento de dados pessoais descrito nesta política aplica-se às operações efetivamente ativas da plataforma: hoje, aos cantões cuja operação está de fato conectada, nomeadamente Zurique. A exigência é inegociável e real: a ativação de Genebra, Vaud ou Friburgo exige um parecer jurídico cantonal prévio de um advogado suíço licenciado (segundo a revisão interna de segurança e conformidade da plataforma), e a DirectTransfer não opera nem trata dados pessoais de corrida nesses três cantões enquanto esse parecer não existir. Estado de implementação, com precisão (a salvaguarda técnica e a decisão jurídica de reativar não são a mesma coisa): o mecanismo técnico concreto que impõe este bloqueio, um gate fail-closed de ativação por cantão aplicado em cada ponto de entrada que cria ou reativa uma autorização cantonal de motorista, já está implementado no serviço de backend da plataforma e coberto por testes automatizados que confirmam que bloqueia corretamente Genebra, Vaud e Friburgo e permite os outros cantões; isto não é apenas uma proposta técnica, a salvaguarda já existe e está verificada hoje, independentemente do ambiente. O que permanece pendente não é este mecanismo técnico, mas o parecer jurídico substantivo de um advogado suíço licenciado que determinará se e quando Genebra, Vaud ou Friburgo poderão ser reativados; até que esse parecer exista, o gate fail-closed continua a rejeitar qualquer tentativa de criar ou reativar uma autorização de motorista nesses três cantões. Esta política será atualizada com o regime cantonal específico no momento em que qualquer novo cantão for ativado.

12Segurança da informação (Art. 8 FADP)

Aplicamos medidas técnicas e organizativas adequadas ao risco para assegurar um nível adequado de segurança dos dados e prevenir violações de dados pessoais (Art. 8 §1-2). O desenho de segurança já congelado inclui controle de acesso baseado em papéis (RBAC) e segurança em nível de linha (RLS) nas tabelas de corrida, documento e dados pessoais, segundo a matriz RBAC e os requisitos de RLS já especificados pela revisão interna de segurança e conformidade da plataforma.

Estado de implementação, com precisão: o controle de acesso baseado em papéis (RBAC) está construído, testado e operacional no serviço de backend da plataforma para os fluxos já construídos até hoje (cadastro do motorista, incluindo o acesso a documentos, segundo a seção 6); os fluxos ainda não construídos (corrida, chat, histórico de corridas) ainda não têm aplicação ativa, porque o módulo subjacente ainda não existe. As políticas concretas de segurança em nível de linha do banco de dados (RLS) permanecem registradas apenas como rascunho interno, explicitamente marcado "STUB, NOT RATIFIED"; este rascunho fixa a intenção funcional em nível SQL para acelerar o trabalho da equipe interna de segurança, mas não constitui a política final; a ratificação pela equipe interna de segurança é uma pré-condição antes de a RLS poder ser afirmada como medida de segurança já ativa em produção, inclusive para os fluxos já construídos. Esta seção descreve portanto o desenho de segurança já congelado e a arquitetura-alvo; a aplicação de RBAC está operacionalmente verificada para os fluxos construídos até hoje, a aplicação de RLS não, pendente dessa ratificação.

Se ocorrer uma violação de dados pessoais suscetível de resultar num risco elevado para os seus direitos da personalidade ou direitos fundamentais, notificamos a PFPDT o mais rapidamente possível (Art. 24 §1) e informamos você diretamente, se necessário para a sua proteção ou se a autoridade o exigir (Art. 24 §4).

13Os seus direitos

Nos termos da FADP, você tem o direito de:

Informação (Art. 25): confirmar se tratamos dados pessoais sobre você e obter, entre outras coisas, a identidade e os dados de contato do responsável, os próprios dados tratados, a finalidade, o prazo de retenção ou o critério para o determinar (seção 9), a origem dos dados quando não coletados diretamente junto a você, e os destinatários (seção 7). Respondemos, em regra, no prazo de 30 dias (Art. 25 §7), sem custos (Art. 25 §6). Este direito não pode ser renunciado antecipadamente (Art. 25 §5).
Correção (Art. 32): pedir a correção de dados pessoais incorretos.
Portabilidade (Art. 28-29): pedir a exportação, num formato eletrônico atual, de dados que tenham sido tratados com o seu consentimento ou em conexão direta com um contrato com você.
Oposição a divulgação indevida (Art. 30-31): a divulgação dos seus dados sensíveis a terceiros exige fundamento de justificação próprio (por exemplo, execução de contrato, Art. 31 §2 al. a); você pode contestar a divulgação sem esse fundamento.
Reclamação à autoridade de supervisão: você pode apresentar uma reclamação à PFPDT (Art. 4).

13.1Direito a ser esquecido: mecanismo atual

A destruição ou anonimização dos dados assim que deixarem de ser necessários é uma obrigação legal do responsável, não uma opção (Art. 6 §4), e o Art. 32 permite pedir a correção de dados incorretos. Mecanismo atual, final enquanto o self-service não for implementado: qualquer pedido de exclusão antecipada dos seus dados é tratado manualmente pelo canal de contato da seção 15; respondemos no prazo do Art. 25 §7 (30 dias), aplicado aqui por analogia ao pedido de exclusão (uma extensão razoável do prazo, não uma garantia idêntica ao âmbito literal do Art. 25 §7, que diz respeito ao direito à informação, não à execução de um pedido de exclusão, e está portanto sujeito a revisão por advogado suíço licenciado antes de ser tratado como prazo definitivo); e confirmamos por escrito a execução do pedido ou, quando aplicável, o fundamento jurídico subjacente a qualquer recusa (por exemplo, uma obrigação legal cantonal ainda vigente de retenção documental, seção 4.2). Um mecanismo de self-service direto para o titular executar este pedido sem intervenção manual poderá ser disponibilizado no futuro; esta seção será atualizada quando isso ocorrer, sem alterar o próprio direito, já garantido pelo mecanismo manual descrito acima.

14Avaliação de impacto sobre a proteção de dados (Art. 22)

Reconhecemos que o tratamento em larga escala de dados pessoais sensíveis, como a verificação documental do motorista (seções 4.2, 6), pode desencadear o dever de realizar uma avaliação de impacto sobre a proteção de dados antes do tratamento, nos termos do Art. 22 §1-2 al. a. Essa avaliação é responsabilidade conjunta da equipe interna de segurança e conformidade e da equipe jurídica interna antes do lançamento, e o seu resultado pode originar ajustes nesta política.

15Contato

Para exercer qualquer dos direitos da seção 13, ou para qualquer pergunta sobre este documento: privacidade@directtransfer.ch.

16Consentimento, clickwrap e registro de auditoria

Quando esta política ou qualquer termo de serviço exigir o seu consentimento (por exemplo, no cadastro da conta, na submissão do documento sensível do motorista (seção 6), ou na aceitação desta própria política), a aceitação é dada por clickwrap explícito, nunca por inação ou navegação silenciosa. Cada aceitação gera um registro de auditoria com, no mínimo: o identificador do usuário que aceitou, a versão exata do documento aceite, e o carimbo temporal da aceitação. Esse registro permite provar, a qualquer momento, o que foi aceite, por quem e quando: uma condição de validade do consentimento voluntário e específico exigido pelo Art. 6 §6 FADP.

A estrutura técnica exata deste registro de auditoria (esquema de tabela, retenção do próprio log de consentimento) é responsabilidade da equipe de arquitetura de dados responsável, segundo a regra interna de governança de engenharia deste projeto sobre a titularidade exclusiva de contratos técnicos partilhados; esta política define o requisito jurídico, não o esquema técnico.

17Alterações a esta política

Podemos atualizar esta política para refletir uma alteração no tratamento de dados, na lei aplicável ou na plataforma. Alteração material é comunicada de forma proeminente antes de produzir efeitos, e cada versão é identificada por número e data, segundo o mesmo mecanismo de registro de versão da seção 16.

Histórico de versões:

Versão 1.0, 2026-08-22: primeira versão final deste documento, em substituição do rascunho de trabalho anterior. Incorpora correções já aplicadas em rodadas anteriores de cruzamento interno de segurança e conformidade e de debate crítico adversarial interno, e fecha a posição final sobre retenção (seção 9), âmbito cantonal ativo (seção 11), divulgação dual FADP/RGPD para o módulo Cargo (seção 10), e o mecanismo do direito a ser esquecido (seção 13.1). Quanto à divulgação da chamada GSM nativa (seção 4.6), fecha o texto de divulgação e apresenta o enquadramento jurídico mais próximo disponível (Art. 19 §2 al. c + Art. 6 §2), mas não fecha, por si só, a confirmação da suficiência jurídica desse enquadramento para o cenário específico; essa confirmação permanece com a revisão interna de segurança e conformidade da plataforma, segundo a nota da própria seção 4.6. Correção pontual em 2026-08-23 (seção 11): o texto anterior descrevia o gate fail-closed de bloqueio cantonal ainda como "uma proposta técnica, não uma decisão"; isso está agora desatualizado. A verificação técnica direta do código confirmou que o mecanismo já está implementado e coberto por testes automatizados; só permanece pendente o parecer jurídico substantivo de um advogado suíço licenciado sobre a reativação desses cantões. Friburgo foi também acrescentado de forma explícita ao lado de Genebra e Vaud, por estar igualmente bloqueado no código.
Versão 1.0, idioma português, 2026-09-19: publicação da mesma substância pública já servida em EN/DE/FR/IT, em português brasileiro, sem acrescentar razão social, sede ou UID.