Rever um acordo de tratamento de dados face ao serviço real

Um acordo de tratamento de dados torna-se útil quando a sua descrição corresponde ao serviço real. Um contrato com aspeto completo pode, ainda assim, descrever os dados errados, omitir um prestador de suporte ou prometer uma eliminação que o produto não consegue executar.

Para um CTO, a revisão liga os compromissos jurídicos à arquitetura, à configuração e aos procedimentos operacionais. Os colegas da área jurídica ou de privacidade interpretam as cláusulas; a engenharia determina se essas cláusulas descrevem a realidade. O resultado deve ser uma decisão defensável sobre o serviço, sustentada por evidências e por uma lista clara das condições por resolver, e não apenas um PDF assinado.

Determine o papel do fornecedor antes de rever as cláusulas

Comece por determinar se o fornecedor atua como subcontratante no tratamento em causa. Nos termos do RGPD, um subcontratante trata dados pessoais por conta do responsável pelo tratamento. Nem todas as relações com fornecedores têm esse papel, e um mesmo fornecedor pode ter papéis diferentes em atividades diferentes.

Uma plataforma de suporte alojada pode tratar os tickets de clientes segundo as suas instruções e, ao mesmo tempo, atuar como responsável pelo tratamento autónomo em parte da administração das suas próprias contas. Se os seus termos permitirem também utilizar o conteúdo dos tickets para finalidades determinadas de forma independente, essa atividade precisa de uma análise separada. Chamar a tudo «melhoria do serviço» não resolve a questão do papel.

Prepare uma breve declaração de âmbito antes de anotar o acordo:

• Identifique a entidade contratante, o produto, o nível de subscrição e as funcionalidades ativadas.
• Descreva porque é que a sua organização utiliza o serviço e de quem são os dados pessoais que este trata.
• Separe o tratamento efetuado por instrução de quaisquer finalidades definidas pelo fornecedor.
• Nomeie o responsável interno pelo serviço e o revisor jurídico ou de privacidade.

Um acordo de tratamento de dados não constitui um fundamento de licitude nos termos do artigo 6.º, nem satisfaz automaticamente os requisitos relativos a transferências internacionais. Essas questões continuam a ser autónomas. Se a sua própria organização for subcontratante, identifique as instruções e as condições de autorização do responsável pelo tratamento a montante antes de contratar o fornecedor como subcontratante ulterior.

Construa uma matriz de revisão do artigo 28.º

O artigo 28.º do RGPD exige um contrato vinculativo ou outro ato normativo elegível que regule a atividade do subcontratante. Este deve descrever o objeto e a duração, a natureza e a finalidade, os tipos de dados pessoais, as categorias de titulares dos dados e os direitos e obrigações do responsável pelo tratamento.

Estes elementos devem identificar o tratamento real. «Todos os dados necessários à prestação dos serviços» pode deixar os revisores sem conseguir determinar se estão abrangidos registos de colaboradores, mensagens de clientes ou anexos sensíveis. Compare os anexos com o produto tal como está configurado, incluindo as integrações opcionais.

Utilize a matriz seguinte para examinar os deveres obrigatórios do subcontratante. A coluna das evidências contém recomendações práticas de revisão, e não uma obrigação legal de obter cada documento indicado.

O subcontratante deve também informar imediatamente o responsável pelo tratamento se, no seu entender, uma instrução violar a legislação de proteção de dados aplicável. Verifique para onde vai essa notificação e quem a pode resolver.

Classifique cada requisito como coberto, pouco claro ou em falta, com a referência da cláusula. Não classifique uma omissão obrigatória como uma simples preferência comercial. O artigo 28.º, n.º 1, exige também que os responsáveis pelo tratamento recorram a subcontratantes que apresentem garantias suficientes; a redação contratual, por si só, não o pode demonstrar.

Acompanhe um registo representativo ao longo do serviço

Escolha um registo realista e siga-o desde a entrada até à eliminação. Num serviço de apoio ao cliente, pode ser um ticket com um nome, um endereço de e-mail, um identificador de conta e um anexo. Prefira dados sintéticos nos testes.

Mapeie a recolha, a entrada por API, o armazenamento principal, a indexação, a análise de dados, o acesso do suporte, as exportações, as integrações, as cópias de segurança e a eliminação. Pergunte que componentes recebem conteúdo e quais recebem apenas metadados. Os logs e os rastreios de diagnóstico contêm muitas vezes identificadores, mesmo quando o âmbito da aplicação principal está corretamente delimitado.

Para cada fase, registe a entidade responsável, a finalidade do tratamento, a localização, a via de acesso e o prazo de conservação. Compare o resultado com o acordo de tratamento de dados, o anexo de segurança, a lista de subcontratantes ulteriores e os mecanismos de transferência.

Preste especial atenção às funcionalidades que os administradores podem ativar sem envolvimento da área de compras: transcrição, enriquecimento, resumos por IA, webhooks externos e gravação de sessões de suporte. Um contrato revisto para o produto base pode não descrever adequadamente o serviço com essas funcionalidades ativadas.

O resultado pode ser um diagrama simples de fluxos de dados e um registo de discrepâncias. Cada discrepância deve identificar a afirmação contratual, o comportamento observado, a consequência, o responsável e a resolução. Por exemplo, «O acordo descreve uma conservação controlada pelo cliente; os logs de diagnóstico são mantidos durante um período fixo» é acionável. «Conservação pouco clara» não basta para encerrar a questão.

Teste as promessas de segurança face à implementação

O artigo 32.º exige medidas de segurança adequadas ao risco. Não impõe uma configuração técnica universal. Avalie as medidas em função da sensibilidade dos dados, do volume, da exposição e das consequências prováveis de um comprometimento.

Um anexo deve explicar o suficiente para avaliar o serviço, sem exigir a divulgação de pormenores sensíveis do ponto de vista da exploração de vulnerabilidades. Dê prioridade ao isolamento entre tenants, ao acesso privilegiado, à autenticação, à cifragem, à resiliência, à recuperação, à gestão de vulnerabilidades e aos testes. Identifique os controlos que o fornecedor opera e as definições que a sua equipa tem de configurar.

Se o acordo prometer um acesso restrito do suporte, pergunte como esse acesso é pedido, aprovado, limitado no tempo e registado. Se prometer cifragem, distinga a proteção em trânsito da proteção em repouso e, depois, determine quem controla as chaves e o que os utilizadores autorizados continuam a poder ler. A cifragem não resolve permissões aplicacionais excessivas.

Quanto à disponibilidade e à recuperação, determine que cópias de segurança existem, como é testada a restauração e se os compromissos contratuais de recuperação abrangem o produto que está a comprar. Mantenha os objetivos comerciais de disponibilidade separados das obrigações de segurança e de privacidade.

Os certificados e os relatórios de garantia podem apoiar a avaliação, mas o seu âmbito é importante. Verifique o serviço, a entidade jurídica, o período de avaliação, as exclusões e as responsabilidades do cliente. Um relatório sobre o fornecedor de alojamento não é evidência de todos os controlos da aplicação SaaS, e uma certificação não demonstra a conformidade com o RGPD. Consulte avaliar a garantia de segurança para a revisão mais alargada das evidências.

Quando o anexo de segurança for incorporado através de uma ligação web, conserve a versão aplicável. Verifique se as alterações podem reduzir a proteção e como os clientes são informados. Trate uma página sem data e alterável como um problema de gestão de evidências a resolver, em vez de presumir que é automaticamente suficiente ou automaticamente inválida.

Acompanhe a cadeia de subcontratantes ulteriores e avalie as transferências em separado

O artigo 28.º, n.º 2, exige autorização prévia por escrito, específica ou geral, para a contratação de outro subcontratante. Em caso de autorização geral, o subcontratante deve informar o responsável pelo tratamento de quaisquer alterações pretendidas quanto ao aumento do número ou à substituição de outros subcontratantes, dando-lhe a oportunidade de se opor. O artigo 28.º, n.º 4, exige que as obrigações de proteção de dados relevantes sejam transmitidas em cadeia; o subcontratante inicial continua a ser plenamente responsável perante o responsável pelo tratamento pelo cumprimento dessas obrigações pelo subcontratante ulterior.

Obtenha uma lista utilizável que indique a identidade jurídica de cada prestador, a sua função, os dados relevantes e os locais de tratamento. Nem todas as dependências de um fornecedor são subcontratantes ulteriores, mas os prestadores de infraestrutura, suporte e análise não devem desaparecer da revisão só por operarem por detrás da interface do produto.

Avalie o mecanismo de alteração:

• O aviso chega a um endereço monitorizado ou a um responsável designado?
• Há informação e tempo suficientes para avaliar a alteração proposta?
• Como é apresentada e resolvida uma oposição?
• O que acontece se não existir uma alternativa aceitável?

Um direito contratual que ninguém consegue exercer na prática é um sinal de alerta. Inscreva a equipa adequada e registe quem avalia os avisos.

O alojamento na UE é relevante, mas não encerra a avaliação das transferências. Examine os destinatários reais, os mecanismos de acesso remoto, as localizações do suporte e as transferências ulteriores. Do mesmo modo, a propriedade estrangeira, por si só, não é uma descrição completa de uma transferência: documente as entidades e as vias de acesso reais.

Quando o capítulo V se aplicar, identifique o mecanismo de transferência relevante e qualquer avaliação ou medida complementar necessária. Mantenha esta análise ligada à revisão do fornecedor, mas distinta da conformidade com o artigo 28.º. Um acordo de tratamento de dados e uma definição de alojamento regional não respondem, por si sós, a todas as questões relativas a transferências.

Torne exequíveis as obrigações de assistência

Notificação de violações e passagem do incidente

Nos termos do artigo 33.º, n.º 2, o subcontratante deve notificar o responsável pelo tratamento sem demora injustificada após ter conhecimento de uma violação de dados pessoais. O responsável pelo tratamento avalia separadamente a notificação à autoridade de controlo, que é obrigatória sem demora injustificada e, sempre que possível, até 72 horas após ter tido conhecimento da violação, a menos que esta não seja suscetível de resultar num risco para os direitos e liberdades das pessoas singulares.

Não dê ao subcontratante o prazo do responsável pelo tratamento como período de espera por defeito. Um contrato prático deve prever uma notificação inicial rápida, canais designados e atualizações progressivas. Um objetivo de notificação acordado é uma recomendação operacional; não substitui o critério legal.

Peça a informação necessária para avaliar os dados, as pessoas e os sistemas afetados, as consequências prováveis, a contenção e a recuperação. O primeiro aviso pode estar incompleto, por isso defina como se seguem as atualizações e as evidências. O responsável pelo tratamento tem também de avaliar se um risco elevado exige a comunicação aos titulares dos dados afetados nos termos do artigo 34.º, sem prejuízo das exceções aí previstas, e documentar a avaliação da violação, incluindo as razões para não notificar. Reveja cuidadosamente o facto que desencadeia a notificação: um processo que aguarda a conclusão da investigação da causa raiz pode atrasar a avaliação do responsável pelo tratamento.

Teste a passagem com um exercício de simulação. Confirme que o aviso chega às equipas de resposta a incidentes e aos revisores de privacidade fora do horário normal de expediente, e não apenas a um gestor de conta.

Pedidos dos titulares dos dados

A assistência do subcontratante deve tornar viável o seu próprio processo de resposta ao exercício de direitos. Teste se os registos podem ser localizados no conteúdo, nos anexos, nos índices e nas exportações, e se o apagamento ou a retificação chegam aos componentes relevantes.

Acorde a via de resposta e o prazo de resposta esperado. Os responsáveis pelo tratamento dispõem normalmente de um mês para responder a um pedido, sem prejuízo das condições de prorrogação do RGPD; a assistência do fornecedor tem de deixar margem para a verificação da identidade, a apreciação jurídica e a entrega segura. Em regra, o fornecedor deve encaminhar para si os pedidos relativos ao tratamento efetuado por sua instrução, em vez de decidir de forma independente o respetivo resultado.

Os encargos e os limites do serviço merecem revisão. As taxas por assistência adicional não são automaticamente proibidas, mas não podem tornar ineficaz a assistência obrigatória. Ligue o procedimento ao seu fluxo de trabalho de pedidos de acesso dos titulares.

Devolução, eliminação e cópias de segurança

No fim do serviço, o artigo 28.º exige a eliminação ou a devolução, consoante a escolha do responsável pelo tratamento, e a eliminação das cópias existentes, salvo se a conservação dos dados for exigida ao abrigo do direito da União ou dos Estados-Membros. Determine o que isso significa tecnicamente antes de comprar.

Verifique a exaustividade da exportação, o formato, a janela de disponibilidade e se os anexos ou a configuração estão excluídos. Quanto à eliminação, distinga registos ativos, caches, réplicas, logs e cópias de segurança. Se a eliminação nas cópias de segurança seguir um ciclo programado, documente o período, as restrições de acesso e as medidas que impedem que registos eliminados sejam reintroduzidos através de uma restauração.

Pergunte como é comprovada a conclusão e como é identificada a conservação legalmente exigida. Evite confiar em «conta encerrada» como prova de que os dados pessoais foram removidos.

Reveja os direitos de auditoria, a responsabilidade e as cláusulas por resolver

As disposições de auditoria devem proporcionar uma garantia significativa, protegendo simultaneamente os outros clientes e os interesses legítimos de segurança. Um agendamento razoável, a confidencialidade e o recurso a relatórios independentes podem tornar as auditorias exequíveis. No entanto, uma cláusula que se limite a certificados, sem via para obter a informação necessária ou tratar preocupações materiais, justifica uma análise jurídica à luz do artigo 28.º, n.º 3, alínea h).

Determine a via de escalada quando as evidências são insuficientes, ocorre um incidente ou uma autoridade exige informação. Analise em conjunto os custos de auditoria, os prazos de pré-aviso e as restrições; o seu efeito combinado importa mais do que qualquer frase isolada.

As cláusulas de responsabilidade precisam de uma avaliação comercial separada. A indemnização prevista no artigo 82.º depende das condições de responsabilidade do regulamento; os subcontratantes não são automaticamente responsáveis por todas as falhas do responsável pelo tratamento. Quando várias partes são responsáveis nos termos do artigo 82.º, as regras podem expô-las à totalidade dos danos, para assegurar uma indemnização efetiva. Um limite contratual não restringe os direitos legais das pessoas singulares. O seu efeito na repartição e no direito de regresso entre as partes precisa de análise jurídica.

Se o fornecedor recusar alterações, distinga três resultados:

• Esclarecimento: obter redação ou evidências fidedignas que resolvam a ambiguidade.
• Aceitação condicional: aprovar um acordo lícito com risco residual comercial ou operacional documentado e salvaguardas especificadas.
• Não avançar: interromper ou reformular o tratamento quando as obrigações exigidas continuem por cumprir.

A aceitação pela gestão não pode tornar lícito um acordo ilícito. O encarregado da proteção de dados (EPD), quando designado, aconselha e controla de forma independente; o responsável de negócio que presta contas toma as decisões sobre o serviço com o contributo das áreas jurídica e de privacidade. Não atribua ao EPD a responsabilidade de determinar as finalidades ou os meios do tratamento.

Examine as funcionalidades de IA como vias de tratamento adicionais

As funcionalidades de IA introduzem entradas, resultados e artefactos intermédios que os anexos mais antigos podem não descrever. Reveja, quando relevante, os prompts, os documentos recuperados, os embeddings, as respostas geradas, o feedback, os registos de monitorização de abusos e o acesso para revisão humana.

Determine se os dados dos clientes são utilizados para treinar ou melhorar modelos, a que finalidades isso serve e que entidade efetua o tratamento. «Sem treino» não é equivalente a «sem conservação», e nenhuma destas promessas prova que os logs de suporte ou os registos de monitorização não contêm dados pessoais.

Verifique se os compromissos se aplicam ao nível de subscrição adquirido, aos endpoints ativados e aos fornecedores de modelos a jusante. Confirme as definições de conservação, as exceções e o comportamento de eliminação. Se um fornecedor alegar anonimização, pergunte o que sustenta essa alegação, em vez de presumir que os artefactos dos modelos são anónimos.

Registe em conjunto o compromisso contratual e as evidências de configuração. Qualquer nova finalidade exige a sua própria avaliação do papel e da licitude; o acordo de tratamento de dados não fornece esse fundamento jurídico. A aplicabilidade do Regulamento da IA é também uma questão separada, que não fica resolvida com a assinatura de cláusulas de subcontratação.

Exemplo prático: software de suporte com resumos opcionais

Suponha, a título ilustrativo, que uma empresa SaaS pretende uma plataforma de suporte com nomes, endereços de e-mail profissionais, texto de tickets e anexos. Os tickets podem conter acidentalmente informação sensível. Uma funcionalidade opcional de IA resume as conversas.

O projeto de acordo de tratamento de dados descreve o tratamento dos tickets e o armazenamento na UE. A análise técnica revela um fornecedor de resumos, acesso do suporte a partir de outra região e uma conservação dos dados de diagnóstico diferente da conservação dos tickets.

A revisão dá origem a quatro ações concretas:

1. Completar o âmbito. Acrescentar à descrição os anexos, os identificadores de diagnóstico e o tratamento por IA; verificar se o fornecedor utiliza algum conteúdo para finalidades próprias.
2. Resolver a cadeia de prestadores. Obter a identidade do fornecedor do modelo, os locais de tratamento, os compromissos de conservação e a cobertura da autorização. Avaliar separadamente as transferências relevantes.
3. Validar o comportamento ao longo do ciclo de vida. Fazer passar um ticket sintético pela exportação e pela eliminação. Obter a explicação sobre a conservação nas cópias de segurança e nos dados de diagnóstico, em vez de presumir que a eliminação do ticket remove todas as cópias.
4. Definir uma condição de ativação. Manter os resumos desativados até que o respetivo contrato e fluxo de dados sejam revistos. Definir o encaminhamento dos avisos de violação e das alterações de subcontratantes ulteriores antes da utilização em produção.

O registo da decisão distingue as evidências recebidas das questões ainda em aberto. Se o serviço principal for aceitável, a aprovação pode excluir explicitamente a funcionalidade de IA. Esse limite tem também de existir na configuração e na gestão de alterações; uma nota no ficheiro da revisão não impedirá que alguém a ative mais tarde.

Conserve a decisão e reabra-a quando o serviço mudar

Mantenha juntos a versão aplicável do contrato, o âmbito do tratamento, o diagrama de fluxos de dados, as evidências de garantia, a avaliação das transferências, o registo de discrepâncias e a aprovação. Registe os riscos residuais aceites, as condições, os responsáveis e as datas de acompanhamento. Conserve a razão pela qual um acordo foi aceite, e não apenas o seu estado.

Reveja de novo quando as finalidades do tratamento, as funcionalidades ativadas, os subcontratantes ulteriores, as localizações ou os termos contratuais mudarem de forma significativa. Inclua como fatores desencadeadores os incidentes significativos e novas evidências de fragilidades nos controlos. Uma revisão agendada complementa estes fatores, em vez de os substituir.

A Secani pode apoiar este fluxo de trabalho modelando o serviço e os prestadores externos, ligando as evidências aos requisitos e às decisões e atribuindo as lacunas da revisão a responsáveis. As conclusões revistas por pessoas, as ligações às fontes, os comentários e as aprovações preservam o raciocínio por detrás da aceitação. Isto liga a revisão do contrato à gestão do risco de terceiros, sem tratar o software como substituto do juízo jurídico ou técnico.

O acordo precisa de uma assinatura manuscrita?

O artigo 28.º, n.º 9, exige a forma escrita, incluindo em formato eletrónico. Uma assinatura manuscrita não é, em si, obrigatória. Conserve a prova da aceitação vinculativa e da versão em vigor; peça aos revisores jurídicos que resolvam as dúvidas sobre a incorporação online ou sobre termos contraditórios.

Todos os subcontratantes ulteriores têm de ser identificados no próprio acordo?

O artigo 28.º não prescreve uma lista fixa no próprio documento. Uma lista mantida atualizada pode sustentar a autorização, desde que o mecanismo forneça a informação exigida, os avisos de alteração e a oportunidade de oposição. Conserve a lista relevante para a sua revisão.

Na próxima revisão de um fornecedor, comece por um fluxo de dados representativo e pela matriz do artigo 28.º. Resolva a discrepância entre as promessas contratuais e o funcionamento observável antes de autorizar o tratamento em produção.