A privacidade não é apenas um documento
Todo produto SaaS moderno tem uma política de privacidade. A maioria delas diz as coisas certas.
Elas descrevem que dados são recolhidos, como são usados, que categorias de destinatários os recebem, durante quanto tempo são conservados e como um cliente pode exercer os seus direitos.
Isso é necessário — mas não é suficiente.
Uma política de privacidade diz-lhe o que um fornecedor promete fazer. A arquitetura do produto diz-lhe o que ele poderia fazer.
Se uma política diz "não vendemos os seus dados", mas a arquitetura é construída sobre infraestrutura de tecnologia publicitária, a política está a suportar muito peso. Se uma política diz "mantemos os seus dados seguros", mas o sistema é sustentado por vinte serviços externos, a política está a fazer promessas sobre partes do sistema que o fornecedor não pode controlar totalmente.
Acreditamos que a privacidade deve ser visível primeiro na arquitetura e descrita depois na política.
O que "pela arquitetura" realmente significa
Privacidade pela arquitetura é a ideia de que a própria estrutura do sistema deve limitar a forma como os dados podem ser recolhidos, acedidos, processados e partilhados.
É a diferença entre "escolhemos não fazer X" e "construímos a plataforma de forma a tornar X impraticável".
A primeira é uma cultura. A segunda é uma restrição.
As culturas mudam. As restrições são estáveis.
As decisões que a moldam
Privacidade pela arquitetura não é uma funcionalidade única. É uma sequência de pequenas decisões, repetidas ao longo dos anos.
Escolher operar componentes internamente em vez de encaminhar dados através de serviços externos. Escolher minimizar as categorias de dados que recolhemos. Escolher não integrar com ecossistemas de publicidade ou rastreamento comportamental. Escolher armazenar dados empresariais em regiões que os nossos clientes esperam. Escolher manter os workspaces isolados. Escolher não explorar conteúdo de clientes para obter insights de marketing.
Nenhuma dessas decisões é dramática por si só. O efeito cumulativo é o que molda a plataforma.
O que deliberadamente não recolhemos
Um exercício útil é o inverso do resumo típico de privacidade.
Não recolhemos perfis comportamentais da sua equipa para segmentação publicitária. Não gravamos reproduções de sessão da utilização do workspace. Não implementamos rastreamento entre sites de redes publicitárias dentro da plataforma autenticada. Não recolhemos dados cuja necessidade não possamos justificar.
Cada ponto de dados adicional que uma plataforma recolhe é uma decisão de privacidade. A maioria das plataformas erra pelo excesso. Nós erramos pelo mínimo.
O que deliberadamente não partilhamos
Não há revenda de informações de clientes. Não há partilha com parceiros de marketing. Não há canalização para corretores de dados. Não há conjunto de dados "anonimizados" licenciado a terceiros.
Quando um fornecedor diz "podemos partilhar dados agregados e anonimizados com os nossos parceiros", vale a pena perceber o que essa frase realmente permite. Nós não quisemos escrevê-la.
O que deliberadamente não conservamos para sempre
A retenção de backups existe por razões de fiabilidade operacional e obrigação regulamentar. Documentamos os nossos períodos de retenção na Política de Privacidade.
Mas, fora dessas janelas de retenção explícitas, eliminamos o que já não precisamos. Não mantemos informações de clientes indefinidamente por defeito. Não mantemos os dados de contas encerradas disponíveis caso "possa voltar". Não acumulamos informações para futuras ideias de produto.
Se não precisávamos de os conservar, eliminamo-los.
Porque a minimização importa
A minimização de dados é um dos princípios centrais do RGPD. Também é boa engenharia.
Cada dado adicional que um sistema armazena é algo que precisa de ser protegido, assegurado, copiado em backup, replicado, mantido em conformidade e, eventualmente, eliminado. Menos dados significam menos superfície para defender.
Para os nossos clientes, isso também significa menos preocupações. A informação que existe é a informação que lá coloca — não uma longa sombra de metadados comportamentais que alguém, algures, possa eventualmente achar útil.
Porque o isolamento importa
Cada workspace KIMISUITE é logicamente isolado de todos os outros. Os dados da sua empresa não se misturam com o conteúdo de outros clientes. As operações entre workspaces não acontecem por defeito. A funcionalidade entre workspaces é opcional e explícita.
Esse isolamento está incorporado na forma como a plataforma funciona, não apenas na política.
Porque a arquitetura supera o marketing
É fácil para qualquer fornecedor escrever "a privacidade está no nosso ADN" numa página de marketing. Não custa nada.
É mais difícil tomar decisões arquitetónicas que imponham limites à própria plataforma — decisões que têm de ser defendidas sempre que surge um requisito concorrente.
As equipas internas vão pedir mais dados comportamentais. As equipas de vendas vão pedir perfis de cliente mais ricos. O marketing vai querer reproduções de sessão. Algum investidor futuro vai sugerir monetizar conjuntos de dados "anonimizados".
A resposta a tudo isso, pela arquitetura e por intenção, é não.
Considerações finais
Uma política de privacidade pode descrever o que um fornecedor quer fazer.
A arquitetura de uma plataforma decide o que um fornecedor pode fazer.
Escolhemos fazer com que as duas coincidam — e mantê-las alinhadas à medida que a plataforma cresce.
Se a sua empresa armazena informações importantes dentro de uma plataforma SaaS, essa correspondência merece ser analisada com atenção.
Continue a ler a Série Trust:
← Anterior: Quem pode aceder aos dados da sua empresa?
→ Seguinte: O que acontece aos seus dados quando cancela?
Inicie o seu teste gratuito de 14 dias · Ver preços da KIMISUITE