# Documentos legais — histórico de versões

Este ficheiro é a resposta a uma pergunta concreta de um cliente: **«o que mudou desde que eu
aceitei?»**. Cada linha diz que documento mudou, quando, e o que passou a ser diferente.

Os textos vivem em `site/legal/` e no `site/privacidade.html`, versionados por git. O git dá, de
borla, a prova de que versão esteve no ar em cada data — não é preciso guardar cópias à parte.

---

## Versões em vigor

| Chave | Documento | Versão | Data | Endereço |
|---|---|---|---|---|
| `termos` | Condições de Utilização | 1.0 | 2026-08-06 | https://desafiosdacidade.com/legal/termos |
| `dpa` | Acordo de Tratamento de Dados (art.º 28.º RGPD) | 1.1 | 2026-08-06 | https://desafiosdacidade.com/legal/tratamento-dados |
| `subprocessadores` | Fornecedores | 1.2 | 2026-08-08 | https://desafiosdacidade.com/legal/fornecedores |
| `privacidade` | Política de Privacidade | 2.0 | 2026-08-06 | https://desafiosdacidade.com/privacidade |

## Impressões digitais (SHA-256)

O que estes números fazem: provam que o texto que uma pessoa aceitou **não foi alterado depois**. Se
o texto mudar sem mudar a versão, o número deixa de bater certo, e isso vê-se.

> ⚠️ **Corrigido a 2026-08-08.** Este parágrafo dizia que o número «entra no catálogo de cada
> aplicação (`lib/legal/documents.ts` no condopilot e no sentinela, `src/config/legal.js` no
> estaleiro) e é gravado em cada registo de aceitação». **Nenhum desses ficheiros existe.** A
> aceitação eletrónica dentro das aplicações está escrita em `specs/aceitacao-termos/SPEC.md` e
> ainda não foi construída; hoje a prova é o contrato em papel. Quando for construída, é aqui que
> os números vão buscar-se.

| Chave | Versão | SHA-256 |
|---|---|---|
| `termos` | 1.0 | `5d3a14f2a9150114632e15a797a46b95b97c708011cd30b2ea6d32b7ed5d9963` |
| `dpa` | 1.1 | `20839695b274a0ad9cf1577160016c6eb8ae3808d903606247ee41c121c5a493` |
| `subprocessadores` | 1.2 | `226ca65c7ddf341afff5e3db3a69b5a42503703e1118f7ed23b348d3eed45264` |
| `privacidade` | 2.0 | `f4c1826bbc67689efcd19e2140cc14b7d3a784376bdb169b4e7b0a00e0a985ba` |

**Como se confere** — sobre o texto **publicado**, que é o que o cliente aceitou:

```bash
curl -s https://desafiosdacidade.com/legal/termos | sha256sum
```

Sobre o ficheiro local, normalizando as quebras de linha para as do git (o repositório está com
`core.autocrlf=true`, por isso no Windows o ficheiro em disco tem `CRLF` e o que é publicado tem `LF`):

```bash
tr -d '\r' < site/legal/termos.html | sha256sum
```

> ✅ **Conferido a 2026-08-06, depois da publicação do `dpa` 1.1:** as quatro impressões digitais
> calculadas sobre o texto servido em `desafiosdacidade.com` são iguais às da tabela acima. O que
> está registado é o que o cliente vê.
>
> ✅ **Conferido a 2026-08-08, depois da publicação do `subprocessadores` 1.2:** a impressão digital
> calculada sobre `desafiosdacidade.com/legal/fornecedores` é
> `226ca65c…d45264`, igual à da tabela, e a página servida diz «Versão 1.2».

---

## Regras de versionamento

- **Correção de gralha ou de redação não é versão nova.** Corrige-se, regista-se aqui como nota, e a
  impressão digital é atualizada.
- **Alteração ao que a DC pode fazer com os dados, ao preço ou aos direitos do cliente é versão
  nova.** Sobe o número, muda a data, e a aplicação volta a pedir a aceitação ao representante legal
  de cada cliente.
- **Fornecedor novo tem aviso prévio de 30 dias** por email a todos os clientes, antes de entrar na
  lista e antes de tratar dados. Não se acrescenta um fornecedor e se pede o clique no mesmo dia.
- **As versões anteriores não se apagam.** Ficam no histórico do git, e é esse histórico que prova o
  que estava no ar em cada data.

---

## Histórico

### 2026-08-08 — `subprocessadores` v1.2 · a inteligência artificial passa a tratar na União Europeia

A página dizia que os pedidos ao Vertex AI seguiam pelo ponto de acesso global da Google e que o
local de tratamento não ficava garantido dentro da União Europeia. **Deixou de ser verdade a
2026-08-08**, e a página estava a declarar pior do que a realidade.

O que mudou, e quando: a alteração ao código é de 2026-08-06 (`VERTEX_LOCATION` passa a valer `eu`
por omissão, com o endereço próprio da multirregião). Chegou à instalação do cliente a 2026-08-08,
com a publicação das funções desse dia. Até lá esteve só no repositório.

Porquê a multirregião e não um centro de dados europeu: a Google só garante o limite territorial nos
endereços de multirregião. Um endereço regional não o garante, e no da Bélgica nem existe a geração
de modelos que usamos.

**Como se verificou** (2026-08-08): a instalação do cliente tem funções que só existem em versões do
código posteriores à alteração; nenhum ficheiro de configuração dessa instalação define
`VERTEX_LOCATION`, pelo que vale o valor por omissão; e o código escreve um aviso sempre que corre no
acesso global, aviso esse que não aparece nos registos. Verificação feita contra o código e contra a
instalação, não contra documentação.

Sobe o número de versão pela mesma razão que o `dpa` 1.1: é um reforço, não uma redução, mas o texto
e a impressão digital têm de continuar a andar a par. Nenhum cliente tinha aceitado a v1.1, por isso
não há re-aceitação a disparar.

⚠️ **O que isto não garante.** A região europeia é o valor **por omissão** do código, não uma trava.
Uma instalação que defina `VERTEX_LOCATION=global` volta a tratar fora da União Europeia. O código
escreve um aviso quando isso acontece, mas não o impede. Enquanto for assim, esta declaração depende
de ninguém definir essa variável.

### 2026-08-06 — `dpa` v1.1 · verificação em dois passos

O Anexo B ganha uma linha, porque a medida passou a existir. Nesse mesmo dia foi ligada a
**verificação em dois passos** em todas as contas da DC que dão acesso a dados de clientes —
alojamento, bases de dados, ficheiros, correio e envio de emails. Antes disso não estava ligada em
todo o lado, e por isso **não constava do Anexo B**: o texto só descreve o que existe.

É um **reforço**, não uma redução — o Anexo B já dizia que as medidas podem ser melhoradas ao longo
do tempo. Sobe na mesma o número de versão, para que a impressão digital e o texto continuem a
andar a par. Nenhum cliente tinha ainda aceitado a v1.0, por isso não houve re-aceitação a disparar.

> ⚠️ **Fica de fora a conta do registo de domínios (Cloudflare)**, onde a verificação em dois passos
> ainda não está ligada. Não guarda dados de clientes — guarda o domínio, e quem entra nessa conta
> redireciona o correio da empresa. Por isso a frase do Anexo B diz «todas as contas **que dão
> acesso a dados de clientes**», e não «todas as contas»: é exatamente o que é verdade hoje. A
> pendência está registada no ponto 3 do fecho do registo de atividades de tratamento, em
> `legal/REGISTO-ATIVIDADES-TRATAMENTO.md` (documento interno). Quando ficar ligada, esta ressalva
> desaparece.

### 2026-08-06 — `subprocessadores` v1.1 · as duas listas

A v1.0 tinha uma omissão de completude, apanhada horas depois de publicar. A página dizia «esta
página diz-lhe quais são» e listava só os fornecedores contratados pela DC — mas as aplicações
falam com mais serviços do que esses.

Passa a ter **duas listas**, e a fronteira entre elas é quem contrata:

1. **Contratados pela DC** — os sete de sempre. A DC paga, a DC tem acordo de tratamento com cada
   um, a DC responde pelos atos deles.
2. **Contratados pelo cliente, em nome próprio** — **Moloni**, **IfthenPay** e **CTT e-Carta** no
   sentinela, **KeyInvoice** no estaleiro, e a **caixa de correio do próprio cliente** no módulo de
   correio do condopilot. Verificado no código a 2026-08-06: as credenciais são do cliente
   («plano Flex/Pro do GABINETE», «login Moloni do gabinete», «o dinheiro entra direto na conta do
   gabinete», «esta chave é do CLIENTE, não da DC» em `estaleiro/functions/src/keyinvoiceConfig.js`).
   **Não são subcontratantes ulteriores da DC** — a relação de proteção de dados é do cliente com
   eles. Ficam listados na mesma, porque um cliente que veja a aplicação a falar com os CTT tem
   direito a saber porquê.

Nenhum cliente tinha ainda aceitado a v1.0, por isso não houve re-aceitação a disparar.

> ⚠️ **TrackingMore — por resolver, e deliberadamente fora da lista.** Segue o rasto das cartas
> registadas quando a ligação direta aos CTT não está disponível (`TRACKINGMORE_API_KEY` no
> sentinela). O dono confirmou a 2026-08-06 que a **conta é da DC** — logo seria subcontratante
> ulterior, e fora do EEE. **Não entrou na lista** porque não se confirmou acordo de tratamento de
> dados com eles: o sítio redireciona hoje para `cwill.com`, cuja política de privacidade nomeia um
> representante na UE e invoca cláusulas contratuais-tipo, mas **não publica acordo de subcontratação
> nem artigo 28.º**, e diz tratar «nos Estados Unidos ou em qualquer outro país onde o grupo esteja
> constituído». Publicar a linha tornaria falsa a frase da secção 5 — «com cada um destes existe
> acordo em vigor». Atenuantes: só lhe é enviado o **número de registo** da carta, sem nome nem
> morada; e o serviço está a ser substituído pela ligação direta aos CTT
> (`sentinela/lib/ecarta/api-sweep.ts` — «correm em paralelo uns dias, antes de desligar a
> TrackingMore»). **Resolver por uma de duas vias:** pedir-lhes o acordo de tratamento por escrito, ou
> desligar o serviço e ficar só com os CTT. Feito isso, a página muda em conformidade.

### 2026-08-06 — primeira publicação

| Chave | Versão | O que mudou |
|---|---|---|
| `termos` | 1.0 | **Documento novo.** Não existia texto de condições de utilização. Cobre: âmbito e aplicações abrangidas, quem aceita e em nome de quem, contas e acessos, utilização permitida, propriedade dos dados do cliente, licença do software, inteligência artificial (rascunhos, revisão humana obrigatória, sem treino de modelos), disponibilidade e cópias de segurança, suporte, preço e faturação, confidencialidade, fim do contrato e destino dos dados, responsabilidade, alterações, lei e foro. |
| `dpa` | 1.0 | **Documento novo**, adaptado da cláusula 8 do contrato-tipo em `MOTOR_50k/PLAYBOOK_PRIMEIROS_EUROS.md` — que era um parágrafo de um contrato de **serviços** e passa aqui a acordo completo de **software**. Cobre o artigo 28.º/3 alínea a alínea: instruções documentadas, confidencialidade, segurança (art.º 32.º), subcontratantes ulteriores com aviso prévio de 30 dias, apoio nos direitos dos titulares, violações de dados em 48 horas, devolução/eliminação no fim, auditoria, transferências internacionais. Inclui Anexo A (descrição do tratamento por aplicação) e Anexo B (medidas de segurança). |
| `subprocessadores` | 1.0 | **Documento novo.** Substitui o anexo por preencher do mesmo playbook. Sete fornecedores identificados por nome e local de tratamento, verificados no código a 2026-08-06: Supabase (Irlanda), Vercel (Irlanda), Google Firebase/Cloud (Bélgica), Anthropic (EUA), Google Vertex AI, Google Workspace, Resend (EUA). Confirmado que existe acordo de tratamento de dados em vigor com cada um. |
| `privacidade` | 2.0 | Revisão da versão de 26 de junho de 2026, que só cobria o site e os pedidos de contacto. Passa a distinguir os **dois papéis** da DC — responsável pelo tratamento no site e na relação com clientes, subcontratante dentro das aplicações — e remete para os documentos próprios. Acrescenta: dados de clientes e faturação, registo da aceitação eletrónica, prazos de conservação concretos, secção sobre inteligência artificial. Os termos de utilização saíram para documento próprio. |

**Notas desta publicação**

- **Inteligência artificial do estaleiro sem região europeia fixada.** Os pedidos ao Vertex AI seguem
  pelo ponto de acesso global da Google (`VERTEX_LOCATION` não está definido em
  `estaleiro/functions/src/ai.js`, e o valor por omissão é `global`). Está declarado como tal na
  página de fornecedores.

  > ⚠️ **Esta nota terminava com uma afirmação falsa, corrigida a 2026-08-08.** Dizia: «Fixar em
  > `europe-west1` é uma linha de configuração no estaleiro; feito isso, a página passa a poder
  > dizer União Europeia.» **Não é verdade.** Um endereço regional não garante a residência dos
  > dados: a Google só o garante nos endereços de **multirregião** (`eu`, `us`). E em `europe-west1`
  > não existe sequer a geração 3.x dos modelos, só a família 2.5, que se reforma a 2026-10-20. A
  > correção que ficou feita foi para a multirregião `eu`, com endereço próprio. Ver a entrada de
  > 2026-08-08 no topo do histórico. **A situação descrita neste parágrafo deixou de valer a
  > 2026-08-08.**
- **A Cloudflare não entra na lista de fornecedores** das aplicações: só serve o site público
  (estatísticas sem cookies) e os registos de domínio, e não trata dados das aplicações. Fica descrita
  na política de privacidade. O acordo de tratamento de dados está em vigor — verificado a
  2026-08-06 no painel da conta (Manage account → Configurations → Preferences → «Data processing
  addendum»), que declara estar incorporado no Self-Serve Subscription Agreement. Não há nada a
  assinar.
- **Como se verificou cada fornecedor** (2026-08-06): Supabase — a aceitação dos termos de serviço
  vale como assinatura do acordo e das cláusulas contratuais-tipo. Vercel — vinculativo ao entrar no
  contrato de serviço, plano pago. Google (Cloud, Firebase e Workspace) — o Cloud Data Processing
  Addendum é incorporado no contrato e cobre os três. Anthropic — o acordo é incorporado por
  remissão nos Commercial Terms. Resend — vinculativo com a aceitação dos termos; trata nos Estados
  Unidos. Nenhum exigiu assinatura à parte.
- **As cópias de segurança prometidas dependem de um passo de instalação.** O texto promete cópias
  diárias com retenção mínima de 7 dias. No Supabase (condopilot e sentinela) isso é automático no
  plano Pro. No estaleiro **não é**: o PITR e o agendamento de cópias do Firestore são um passo
  manual do provisionamento (`estaleiro/_docs/SETUP-L1.md` §11) e têm de estar ligados em **cada
  instalação de cliente real**. Confirmar instalação a instalação antes de a promessa valer.
- **Revisão jurídica.** Estes textos foram escritos internamente. Recomenda-se revisão pelos PLL
  Advogados, que pode correr em paralelo com o trabalho dentro das aplicações — não o bloqueia.