Política de Privacidade

1. Quem somos e o que esta política cobre

A Tá Marcado (tamarcado.pt) é uma plataforma de marcações online que negócios — barbearias, cabeleireiros, estúdios, gabinetes e semelhantes — usam para publicar a sua agenda e receber marcações.

Esta política cobre o painel de gestão, a página pública de marcação de cada negócio, a consulta privada do cliente e os percursos de privacidade da plataforma. O website informativo e o formulário externo de contacto têm avisos próprios em /privacidade-website e /cookies-website.

Não cobre o que cada negócio faz com os dados fora da plataforma, nem os sites, redes sociais ou sistemas próprios desse negócio.

2. Os dois papéis: quando somos responsáveis e quando somos subcontratantes

Há dois tratamentos diferentes nesta plataforma, e é importante não os confundir.

Dados das marcações. Quem decide recolhê-los é o negócio onde marca: é ele que define os serviços, os horários e as políticas, e é ele o responsável pelo tratamento. Nós tratamos esses dados por conta dele, como subcontratantes, e apenas para lhe prestar o serviço. As instruções e as garantias constam do Acordo de Subcontratação, que faz parte do contrato com cada negócio.

Dados de conta, subscrição, faturação, segurança e operação da plataforma. Aqui somos nós o responsável autónomo: decidimos que dados são precisos para manter contas, cobrar a subscrição, prevenir abuso e manter o serviço a funcionar.

Na prática: se quer saber por que motivo o seu contacto está na agenda de um negócio, ou pedir que seja apagado dessa agenda, o interlocutor é esse negócio, e nós ajudamos a executar o pedido. Se o pedido é sobre a sua conta de utilizador da plataforma ou sobre a subscrição, o interlocutor somos nós.

3. Dados de quem cria conta e gere um negócio

Para criar conta pedimos um endereço de email e uma palavra-passe. A autenticação é feita pelo Firebase Authentication, da Google, e é lá que o email e a palavra-passe ficam guardados — a palavra-passe nunca chega ao nosso servidor em forma legível nem é guardada por nós.

O registo que guardamos sobre um utilizador na nossa base de dados é deliberadamente mínimo: um identificador opaco, a data do último início de sessão e a versão do esquema. O email não é copiado para esse registo.

Para faturar a subscrição guardamos um perfil de faturação com o nome e o país da entidade. A morada fiscal e o NIF, quando fornecido, são recolhidos e conservados pelo Stripe, que emite a cobrança e calcula o IVA; não são copiados para a nossa base de dados. O email da conta é enviado ao Stripe para associar o cliente à cobrança.

Guardamos ainda a ligação entre cada utilizador e cada negócio — a função, proprietário ou colaborador — e, quando aplicável, a que profissional corresponde.

Nunca recebemos nem guardamos dados de cartão. O pagamento decorre em páginas do Stripe.

4. Dados de quem faz uma marcação

Para marcar são pedidos o nome e um contacto — email ou telemóvel. O idioma da marcação é guardado, porque todas as mensagens sobre ela são enviadas nesse idioma. Se marcar mais do que uma vez com contactos diferentes, o registo de cliente passa a guardar os dois canais.

A marcação guarda um instantâneo imutável do que foi contratado: serviço, profissional, duração, preço, modalidade (presencial ou online) e a versão das políticas do negócio em vigor nesse momento. Esse instantâneo não contém o seu nome nem os seus contactos: aponta para o registo de cliente através de um identificador opaco.

O negócio pode escrever notas internas sobre clientes e marcações. As notas de cliente são visíveis apenas aos proprietários; os colaboradores só consultam as notas das marcações da sua agenda. Estas notas não podem conter dados de saúde: a plataforma proíbe expressamente conteúdos e funcionalidades de natureza clínica.

O registo de cliente guarda contadores de faltas assinaladas pelo negócio e de cancelamentos pelo cliente. São informativos e não bloqueiam ninguém.

Não pedimos idade nem ano de nascimento. No programa Loyalty, o cliente pode fornecer opcionalmente o dia e o mês do aniversário; são guardados com a origem e o histórico de alterações para aplicar as regras do programa. Também são conservadas as preferências de comunicação e a respetiva prova. A recolha destes dados não ativa por si só envios.

Reconhecemos que o nome de um serviço ou de um profissional pode, por si só, sugerir informação sobre saúde. É por isso que os eventos de calendário e as mensagens são desenhados para não expor mais do que o necessário, e que os dados clínicos são proibidos em todo o produto.

5. Verificação do contacto e código de uso único

Ainda não ativo

Antes de uma marcação feita na página pública ser aceite, o contacto tem de ser provado. Enviamos um código de seis dígitos por email ou SMS e é preciso devolvê-lo.

O código nunca é guardado. É derivado, no momento da comparação, a partir de um valor aleatório que muda a cada envio. A nossa base de dados não o contém, nem em claro nem cifrado, e o registo do trabalho de envio também não.

O desafio guarda o destino — o email ou o número — em claro, porque alguém tem de saber para onde enviar a mensagem. Esse registo é apagado automaticamente pouco depois de deixar de valer; ver a secção de conservação.

Um código vale 10 minutos, admite 5 tentativas, tem 60 segundos de intervalo entre envios e um máximo de 5 envios por hora para o mesmo destino em cada negócio. Existem limites adicionais por origem do pedido e por negócio.

Depois de o contacto ser provado, o dispositivo recebe um cookie que evita repetir o código durante 60 dias nesse negócio. É explicado na secção dos cookies.

O envio da mensagem depende dos canais descritos na secção das mensagens, que ainda não estão ativos à data desta versão. A geração, a verificação e os limites descritos acima já funcionam como aqui se descreve.

6. Dados de quem visita a página pública

Visitar a página pública de um negócio não exige conta nem contacto.

Para travar abuso — envio de códigos em massa, tentativas de adivinhar códigos, marcações automatizadas — guardamos contadores por origem do pedido, por negócio e, na criação de marcações, pelo contacto usado. Nenhum desses valores é guardado como o escreveu: é transformado num valor irreversível com uma chave secreta, e o que fica na base de dados é esse valor mais um instante. O endereço IP nunca é guardado, e em IPv6 o contador é por bloco /64 e não por endereço, porque uma ligação doméstica recebe um /64 inteiro.

Usamos o Cloudflare Turnstile no envio de códigos e na criação de marcações, para distinguir uma pessoa de um script. É um desafio anti-bot sem puzzles e sem seguimento entre sites.

Não usamos publicidade, cookies de marketing nem ferramentas de analítica de audiências. Não há perfilagem nem decisões automatizadas com efeitos jurídicos sobre si.

7. Mensagens que enviamos

Ainda não ativo

A plataforma envia mensagens transacionais sobre uma marcação: confirmação (com ficheiro de calendário e um link de consulta), alteração, cancelamento, confirmação de reembolso e um lembrete antes da hora marcada.

Quando as notificações forem ativadas, o email e o SMS serão enviados pela Arpoone, plataforma operada pela SEND IT — Software e Serviços para Telecomunicações, S.A., em Portugal.

As mensagens vão no idioma da marcação. O SMS inclui sempre o link curto de consulta e cancelamento.

Não enviamos marketing. Não existe subscrição de newsletter neste produto.

Esta secção descreve comportamento já desenhado e ainda não ativo à data desta versão.

8. O que não guardamos e o que não fazemos

As garantias mais úteis de uma política são as negativas, e estas correspondem a decisões concretas de construção do sistema.

Códigos de verificação não são guardados: são derivados no momento da comparação.

Contactos não são usados como chave de pesquisa em claro. O índice que impede duplicar a mesma pessoa guarda um valor irreversível derivado do contacto, não o contacto.

Os registos de auditoria — quem publicou, quem cancelou, quem reembolsou — guardam identificadores, montantes e o autor da ação. Nunca guardam nomes, emails nem telefones.

Os registos técnicos não contêm email, telefone, token, código nem conteúdo da marcação. O serviço de relatórios de erro corre com o envio de dados pessoais desligado em todos os ambientes, e os relatórios gerados no servidor são adicionalmente limpos de cookies, cabeçalhos, corpo do pedido, endereço IP e email antes do envio. A gravação de sessão está desligada.

Não guardamos dados de cartão nem de outros meios de pagamento.

Não usamos dados identificáveis para marketing, para comparações entre negócios nem para treinar modelos de inteligência artificial.

Não vendemos dados pessoais.

9. Cookies

Usamos apenas cookies necessários ao funcionamento do serviço. Não há cookies de publicidade, de analítica de audiências nem de redes sociais.

Os cookies de sessão e de verificação definidos por nós são HttpOnly (não legíveis por JavaScript), seguem SameSite=Lax e são Secure em produção. O tm_otp e o tm_vc_ não contêm o contacto nem o código; as sessões privadas do cliente e de privacidade contêm uma credencial opaca. O tm_session é emitido pelo Firebase Authentication e transporta a identidade autenticada, incluindo o email da conta.

O desafio anti-bot é carregado a partir de challenges.cloudflare.com e a Cloudflare pode colocar cookies técnicos próprios para o executar. O pagamento decorre em páginas do Stripe, que usa cookies próprios no domínio dele. Nesses casos aplicam-se as políticas desses fornecedores.

Entendemos que os cookies que definimos são necessários ao serviço que o utilizador pede e, por isso, não sujeitos a consentimento prévio. O que mais merece confirmação na revisão jurídica é o tm_vc_: dura 60 dias e é uma conveniência — evita repetir o código — e não uma condição para marcar.

10. Com que fundamento tratamos cada coisa

11. Durante quanto tempo guardamos

A tabela separa o que já está implementado, com o prazo exato que o sistema aplica, do que ainda é uma proposta a validar. A separação é deliberada: preferimos dizer o que ainda não está decidido a apresentar um prazo que não corresponda ao que o sistema faz.

Os prazos marcados como proposta ainda não estão fechados e têm de ser validados juridicamente antes da abertura pública. Estão aqui como proposta concreta para essa revisão, não como compromisso em vigor.

12. Com quem partilhamos

Não vendemos nem cedemos dados pessoais. Partilhamos apenas com os fornecedores necessários para prestar o serviço, e apenas o necessário.

As linhas do Google Calendar e do envio de mensagens dizem respeito a funcionalidades ainda não ativas. A Kapta e a Moloni tratam apenas a faturação da nossa subscrição, em que somos responsáveis autónomos, e nunca os dados das marcações; por isso não constam do anexo do Acordo de Subcontratação.

13. Transferências para fora do Espaço Económico Europeu

A base de dados está numa multirregião europeia e a aplicação corre em Frankfurt. Há, ainda assim, transferências para fora do EEE que assumimos expressamente.

O Firebase Authentication, onde ficam as contas e as palavras-passe de quem gere um negócio, é operado pela Google nos Estados Unidos. É uma característica do serviço e não uma escolha de configuração nossa.

Alguns dos restantes fornecedores são empresas dos Estados Unidos ou têm operações lá, mesmo quando os dados ficam alojados na Europa.

Estes fornecedores declaram apoiar-se em Cláusulas Contratuais-Tipo da Comissão Europeia e, quando aplicável, no EU-U.S. Data Privacy Framework. Os mecanismos concretos, fornecedor a fornecedor, têm de ser confirmados e citados na revisão jurídica deste documento.

14. Os seus direitos e como exercê-los

Tem direito a aceder aos seus dados, corrigi-los, apagá-los, limitar ou opor-se ao tratamento, e à portabilidade. Quando o tratamento assenta em consentimento, pode retirá-lo a qualquer momento, sem afetar o que foi feito antes.

Pode escrever para geral@tamarcado.pt. A plataforma dispõe também de um percurso de pedidos de acesso, portabilidade, correção e apagamento por negócio, cuja disponibilização depende da ativação do envio do código de verificação. O contacto por email mantém-se disponível.

Antes de responder temos de confirmar a identidade por meio proporcional ao pedido. No percurso da plataforma, a prova usa um código enviado ao email associado ao titular nesse negócio: dura 10 minutos, permite 5 tentativas e cria uma sessão de 30 minutos. Não dá acesso aos dados de outros titulares ou negócios.

Os pedidos sobre dados de marcações são tratados negócio a negócio e dependem da instrução do respetivo proprietário, enquanto responsável pelo tratamento. A cópia do titular inclui apenas os seus dados abrangidos, incluindo os pertinentes de Loyalty, Reviews e analítica; não inclui a exportação global, dados de terceiros, notas internas indiscriminadas ou credenciais utilizáveis.

O apagamento e a anonimização exigem instrução verificada e uma política de conservação aprovada para as classes abrangidas; prazos marcados como proposta não autorizam eliminação automática. As correções são propagadas às cópias abrangidas e revogam acessos dependentes. O apagamento da conta de autenticação tem um percurso separado, exige autenticação recente e ausência de acessos ou obrigações pendentes; encerrar um negócio não apaga uma conta que serve outros negócios.

As cópias de acesso e portabilidade ficam disponíveis durante 1 hora após ficarem prontas. A sessão e a autorização são verificadas novamente em cada download; obter uma ligação não prolonga essa hora. O fim do acesso comercial não elimina os percursos necessários para exercer direitos.

Se entender que o tratamento viola a lei, pode reclamar junto da Comissão Nacional de Proteção de Dados (www.cnpd.pt).

15. Segurança

As regras de acesso direto à base de dados negam tudo: nenhum browser lê ou escreve dados diretamente. Todo o acesso passa pelo servidor, que verifica a sessão, a pertença ao negócio e a função antes de qualquer operação.

O browser nunca define preços, negócio, conta de pagamento, permissões nem o estado final de uma marcação.

Os pedidos públicos que escrevem dados passam por limitação de abuso antes de tocarem na base de dados, e o envio de códigos e a criação de marcações passam também por um desafio anti-bot.

Os eventos recebidos do Stripe são verificados por assinatura criptográfica antes de serem aceites.

Os segredos são separados por ambiente e rodados quando necessário.

A autenticação multifator para administração tem implementação própria, mas a sua ativação e inscrição operacional ainda têm de ser comprovadas. Este rascunho não a apresenta como uma proteção já ativa.

Nenhuma medida técnica torna um sistema inviolável. Se ocorrer uma violação de dados que implique risco elevado, cumprimos os deveres de notificação previstos no RGPD.

16. Google Calendar, Google Meet e Limited Use

Ainda não ativo

A integração Google Calendar e Google Meet ainda está em preparação. Quando estiver disponível, a ligação de um calendário por profissional será opcional, desligada por defeito e revogável. Estas condições descrevem o tratamento previsto, não uma funcionalidade já ativa.

A autorização permitirá listar os calendários para escolher um, consultar disponibilidade e ler, criar, atualizar e cancelar eventos de marcações no calendário escolhido. Não será pedido acesso ao Gmail, Drive, contactos ou gravações do Meet. O Meet será criado através do evento Calendar quando aplicável.

O refresh token, que permite renovar o acesso sem pedir nova autorização em cada utilização, será guardado cifrado com Google Cloud KMS. As chaves serão separadas entre ambientes e a cifra será vinculada ao negócio, profissional e utilizador que autorizou a ligação. Os tokens de acesso temporários não serão incluídos em logs.

De eventos externos serão conservados apenas o identificador opaco, o início, o fim e o estado necessário para determinar indisponibilidade. Títulos, descrições e participantes não serão pedidos nem guardados para este efeito. Estes dados serão usados exclusivamente para disponibilidade e sincronização de marcações.

Os eventos criados pela plataforma terão o título “Reserva”, horário, referência interna opaca e um link autenticado para o painel. Não incluirão nome, email, telefone, serviço ou notas do consumidor, que não será adicionado como participante.

Não venderemos dados Google nem os usaremos para publicidade, avaliação de crédito ou treino de modelos de inteligência artificial de uso geral. As transferências serão limitadas à funcionalidade solicitada, segurança, obrigações legais ou demais casos expressamente permitidos pela política Google. Não haverá leitura humana de calendários na operação normal; qualquer exceção terá de respeitar os requisitos específicos dessa política, incluindo consentimento explícito para os dados em causa quando exigido.

Ao desligar, o fluxo implementado bloqueia nova sincronização e regista a revogação da autorização e o encerramento dos canais de alterações. A limpeza é retomável: o token cifrado necessário à revogação só é removido após a sua confirmação, e os dados de disponibilidade derivados da ligação são limpos. A autorização também pode ser retirada nas ligações a terceiros da Conta Google. A expiração das cópias de segurança segue o respetivo ciclo; um restauro tem de reaplicar eliminações e reconciliar correções antes de reabrir acesso. Isto não promete remoção instantânea de todas as cópias nem comprova ativação ou execução real da integração.

Compromisso de Limited Use: Tá Marcado's use and transfer of information received from Google APIs to any other app will adhere to the Google API Services User Data Policy, including the Limited Use requirements. Em português: a utilização e a transferência, para qualquer outra aplicação, de informação recebida de APIs do Google respeitam a Política de Dados de Utilizador dos Serviços de API do Google, incluindo os requisitos de Limited Use.

• Política Google API Services User Data Policy (inclui Limited Use)
• Gerir ligações a terceiros na Conta Google

17. Menores

A plataforma destina-se a negócios e a quem marca um serviço para si. Não recolhemos idade nem data de nascimento e não dirigimos o serviço a crianças.

Quando uma marcação é feita para um menor, é feita por quem tem responsabilidade sobre ele, e é o negócio — enquanto responsável pelo tratamento — que a recolhe nessas condições.

18. Alterações a esta política

Esta política tem versão e data, indicadas no topo. Quando mudarmos algo com impacto para si, atualizamos a versão e, no caso dos negócios com subscrição ativa, avisamos pelos canais de contacto da conta.

19. Contactos

GD Projects, Lda., Rua Dom Diniz, n.º 45, Burinhosa, Pataias, 2445-042 Pataias, freguesia de Pataias e Martingança, concelho de Alcobaça, distrito de Leiria, NIF 519433858, Conservatória do Registo Comercial de Coimbra, NIPC 519433858 — Insc. 1, AP. 11/20260515.

Para qualquer questão sobre esta política ou sobre os seus dados: geral@tamarcado.pt.

Não está designado Encarregado de Proteção de Dados, por não ser exigível à natureza e à escala deste tratamento.

Autoridade de controlo: Comissão Nacional de Proteção de Dados, www.cnpd.pt.