Avaliar fornecedores de chatbot: DPA, subprocessadores e transferências internacionais

Um fornecedor de chatbot pode apresentar uma demonstração convincente, uma região da UE e um Acordo de Processamento de Dados (DPA) pronto – e, ainda assim, deixar questões cruciais em aberto. Afinal, não é apenas o chatbot visível que processa dados. Frequentemente, APIs de modelos, alojamento, bases de dados vetoriais, análise de erros, ferramentas de suporte, serviços de e-mail e cópias de segurança (backups) estão envolvidos na prestação do serviço. Para os operadores de sites, o que conta é a cadeia de processamento auditável, e não uma palavra-chave sobre privacidade numa página de vendas.

Esta lista de verificação ajuda a realizar uma avaliação estruturada do fornecedor antes da aquisição e do lançamento. Trata-se de uma orientação prática e não de aconselhamento jurídico. Papéis, bases legais, obrigações de informação e mecanismos de transferência devem ser avaliados para o caso de uso concreto; em situações de risco acrescido, categorias especiais de dados ou questões contratuais em aberto, deve-se envolver os encarregados da proteção de dados ou consultoria jurídica qualificada.

Compreender o fluxo de dados antes de avaliar o contrato

A questão central não é apenas "Onde está localizado o servidor?", mas sim: quais dados pessoais chegam a que pessoa jurídica, quando, por que razão e por quanto tempo? Um visitante pode introduzir nomes, endereços de e-mail, números de cliente ou texto livre no chat. Além disso, são gerados endereços IP, carimbos de data/hora, informações do dispositivo, identificadores de sessão, históricos de conversas, avaliações e registos técnicos (logs). Mesmo numa conversa supostamente anónima, a combinação de múltiplos atributos pode dar origem a um dado pessoal.

Portanto, antes de rever o contrato, desenhe um mapa simples do fluxo de dados. Este deve incluir, no mínimo: widget do navegador, plataforma do chatbot, base de conhecimento, fornecedor do modelo, serviços de análise e monitorização de erros, acessos de suporte, backups e rotas de eliminação. Para cada etapa, registe o operador, país, finalidade, categorias de dados, período de retenção e possíveis acessos remotos. Uma declaração de "Alojamento na UE", por exemplo, não responde se uma equipa de suporte fora do Espaço Económico Europeu (EEE) pode aceder aos registos em produção.

Determinar as funções de proteção de dados por finalidade

Determinar se um fornecedor é um subcontratante (processor) ou um responsável pelo tratamento (controller) para finalidades específicas depende da sua atividade real. As Diretrizes 07/2020 do Comité Europeu para a Proteção de Dados (EDPB) esclarecem esta distinção. Um fornecedor pode processar dados de conversas sob instruções documentadas, mas reivindicar uma função diferente para certas finalidades próprias de segurança, faturação ou melhoria de produto. Certifique-se de que cada finalidade, função respetiva e base legal sejam explicitamente atribuídas. Um DPA não cobre automaticamente finalidades autónomas do fornecedor.

Avaliar o DPA: os conteúdos obrigatórios devem corresponder ao serviço real

O Artigo 28.º do RGPD exige que os responsáveis pelo tratamento utilizem apenas subcontratantes que apresentem garantias suficientes para a implementação de medidas técnicas e organizativas adequadas. O contrato deve definir, entre outros pontos, o objeto e a duração, a natureza e finalidade, os tipos de dados, as categorias de titulares dos dados, bem como os direitos e obrigações do responsável pelo tratamento. Acrescem a isto instruções documentadas, confidencialidade, segurança, assistência nos direitos dos titulares, eliminação ou devolução, e prestação de informações e cooperação em auditorias.

Compare o DPA não apenas com uma lista de controlo genérica, mas com o seu mapa de fluxo de dados e o plano tarifário contratado. Um bom contrato descreve claramente a operação do chat, o treino ou indexação da base de conhecimento, o registo de logs, os acessos de suporte e funcionalidades opcionais. Termos vagos e genéricos como "melhoria do serviço" devem ser detalhados em dados específicos, finalidades, opções de escolha e funções.

• Instruções: Está claro que o conteúdo e os metadados são processados apenas para finalidades documentadas do cliente? Que configuração conta como instrução?
• Uso para modelos: Prompts, respostas ou conteúdos carregados são utilizados para treino geral de modelos ou melhoria de produtos? Se não, isso deve ser contratualmente e tecnicamente verificável; se sim, a função e a base legal devem ser avaliadas separadamente.
• Eliminação: Existem prazos concretos para históricos de conversa, logs, índices vetoriais, backups e cópias de suporte? O que acontece após a cessação do contrato?
• Segurança: Controlos de acesso, segregação de clientes (multitenancy), encriptação, registos de acesso, gestão de vulnerabilidades e processos de incidentes estão descritos?
• Assistência: O DPA regula de forma prática a exportação, retificação, eliminação, acesso a dados, incidentes de segurança e, se aplicável, Avaliações de Impacto sobre a Proteção de Dados (AIPD)?
• Comprovativos: Relatórios de auditoria, certificações ou outros comprovativos sólidos estão disponíveis e aplicam-se exatamente aos serviços e locais utilizados?

Certificados e relatórios de auditoria podem fornecer indicações valiosas, mas não substituem a análise do processo de tratamento específico nem cláusulas contratuais adequadas. Mesmo um DPA padronizado é apenas tão bom quanto os seus anexos preenchidos e a sua conformidade com a realidade técnica.

Subprocessadores: controlar nomes, funções e alterações

De acordo com o Artigo 28.º, n.º 2 do RGPD, um subcontratante não pode recorrer a outro subcontratante sem a autorização prévia, específica ou geral, por escrito do responsável pelo tratamento. No caso de uma autorização geral, o subcontratante deve informar sobre quaisquer alterações pretendidas relativas à adição ou substituição de outros subcontratantes, dando a possibilidade de oposição. As Perguntas e Respostas da Comissão Europeia sobre Cláusulas Contratuais-Tipo também esclarecem que meras categorias não bastam: cada subprocessador deve ser identificado individualmente.

Exija uma lista atualizada e exportável contendo a razão social, país, serviço específico prestado e dados afetados. Além disso, verifique se a empresa é apenas a contraparte contratual ou se o processamento ocorre efetivamente em múltiplas localizações. Especialmente relevantes são os fornecedores de modelos e embeddings, alojamento em nuvem, bases de dados, CDN, monitorização, análise de erros, suporte, e-mail e backup. Para cada entrada, deve ser transparente se os dados são armazenados, apenas transitam ou podem ser visualizados por pessoal técnico.

O processo de alteração também deve fazer parte da avaliação: como os clientes são notificados, qual é o prazo de pré-aviso e o que acontece em caso de oposição fundamentada? Um e-mail no dia da alteração sem possibilidade de resposta técnica ou contratual útil tem pouco valor. Esclareça se é possível optar por uma configuração alternativa, desativar a funcionalidade ou, em último caso, realizar uma rescisão organizada com exportação de dados. Para subprocessadores subsequentes, as mesmas obrigações de proteção de dados devem ser transmitidas; o subcontratante inicial permanece responsável perante o responsável pelo tratamento pelo cumprimento dessas obrigações.

Transferências para países terceiros: verificar mecanismo e efeito real

O Capítulo V do RGPD aplica-se às transferências de dados pessoais para países terceiros e a subsequentes transferências. Uma transferência pode ocorrer não apenas pelo armazenamento permanente; um acesso administrativo, um acesso de suporte ou uma consulta por um serviço fora do EEE também podem ser relevantes. Portanto, atribua a cada seta no seu mapa de fluxo de dados um país de destino, um destinatário e um mecanismo de transferência.

1. Decisão de adequação: Verifique na lista atualizada da Comissão Europeia se a decisão, o território, o setor e o destinatário específico estão cobertos. Em quadros regulatórios limitados, a mera presença de uma sucursal num país não é suficiente.
2. Garantias adequadas: Na ausência de uma decisão de adequação aplicável, podem ser utilizados instrumentos ao abrigo do Artigo 46.º do RGPD. Frequentemente, utilizam-se as Cláusulas Contratuais-Tipo (SCCs) da Comissão Europeia. O módulo, as partes, os anexos, a descrição da transferência e as medidas técnicas devem corresponder à cadeia real.
3. Avaliação de eficácia: Um documento de SCCs assinado não encerra automaticamente a verificação. As Recomendações finais 01/2020 do EDPB descrevem um processo baseado no risco: mapear transferências, identificar o instrumento, avaliar a legislação e a prática do país terceiro, adotar medidas suplementares se necessário, cumprir formalidades e reavaliar periodicamente.

As medidas técnicas suplementares devem ser proporcionais ao risco concreto. A encriptação, por exemplo, só é efetiva se a gestão das chaves, os direitos de acesso e a finalidade do processamento forem considerados. Um fornecedor de modelos que precisa de processar texto em claro e possui acesso às chaves representa uma situação completamente diferente de um armazenamento de backup puramente encriptado. Declarações genéricas como "AES-256" ou "em conformidade com o RGPD" não substituem essa análise. Da mesma forma, as exceções do Artigo 49.º do RGPD não são um caminho padrão viável para o processamento SaaS rotineiro e planeado.

Exemplo prático: região da UE com cadeia de serviços global

Suponha que um chatbot armazena a sua base de dados principal em Frankfurt. Contudo, as respostas são geradas pela API de um modelo de uma empresa sediada nos EUA, os relatórios de erros vão para outro serviço e uma equipa de suporte global pode abrir registos de conversas em casos de escalonamento. Neste caso, "dados alojados na UE" descreve apenas uma fração do sistema.

A due diligence deve separar quatro perguntas: que conteúdos saem do EEE para gerar a resposta do modelo? Os prompts são armazenados ou utilizados para outras finalidades nesse local? Os relatórios de erros contêm texto simples, identificadores ou apenas dados técnicos minimizados? Em que condições o suporte fora do EEE pode aceder aos dados? Só depois é possível avaliar o instrumento de transferência, as medidas suplementares e o risco residual.

Tecnicamente, o operador do site pode reduzir o risco: desativar campos de registo desnecessários, remover dados sensíveis das entradas antes de chamadas externas, definir prazos curtos de retenção, separar áreas sensíveis do bot público, isolar fontes de conhecimento por cliente e registar os acessos do suporte mediante aprovação. Para saber como separar um bot público de um portal de clientes de forma limpa, consulte o artigo Chatbot de IA público vs. Portal de clientes. No caso de ficheiros enviados, a lista de verificação sobre inspeção de ficheiros, proteção de dados e handoff complementa a avaliação do fornecedor.

Decisão baseada em semáforo em vez de intuição

Ponto de verificação	Verde	Amarelo	Vermelho
Fluxo de dados	Completo, atualizado e associado ao plano	Acessos individuais ou locais em aberto	Apenas alegações de marketing sobre região da UE
DPA	Finalidades, dados, prazos e apoio concretos	Ajustes necessários antes do lançamento	Sem vinculação a instruções ou regras de eliminação
Subprocessadores	Lista nominativa com país e função	Processo de alteração impraticável	Apenas categorias genéricas ou cadeia desconhecida
Transferência internacional	Mecanismo, âmbito e avaliação comprovados	Medidas ainda por verificar	"Servidor na UE" usado para justificar todas as transferências
Operação	Responsável, revisão agendada e plano de saída testado	Comprovativos sem data fixa de revisão	Sem monitorização após a assinatura do contrato

Um ponto amarelo não invalida automaticamente um fornecedor, mas exige um responsável, um prazo e um critério de aceitação verificável. Um ponto vermelho numa cadeia de processamento central deve bloquear a entrada em produção até que o contrato, a configuração ou a escolha do fornecedor sejam ajustados. Documente também os riscos residuais aceites e a pessoa responsável por essa decisão.

Lista de verificação rápida antes do lançamento para operadores de sites

• O mapa do fluxo de dados e as funções por finalidade estão aprovados.
• O DPA e os anexos correspondem ao plano, às funcionalidades, aos tipos de dados e aos prazos de retenção.
• Todos os subprocessadores estão documentados nominativamente, com país, função e processo de alteração.
• Cada transferência internacional possui um mecanismo adequado e atualizado, juntamente com medidas suplementares, se necessário.
• O treino de modelos ou a utilização própria de dados do chat está esclarecido e configurado conforme acordado.
• Registos de logs, acesso de suporte, exportação de dados, eliminação e encerramento do contrato foram testados na prática.
• Os avisos de privacidade e a interface do chat explicam o tratamento de dados de forma clara; os utilizadores não são induzidos a inserir dados sensíveis desnecessários.
• Foi verificado se uma Avaliação de Impacto sobre a Proteção de Dados (AIPD) é necessária para o caso de uso específico.
• Existe um responsável para monitorizar alterações nos subprocessadores, mecanismos de transferência, funcionalidades e comprovativos de segurança.

Como complemento, vale a pena consultar a visão geral em Chatbots de IA e RGPD, bem como o guia para analytics de chatbots com minimização de dados. Desta forma, a aquisição, a configuração técnica e a operação contínua não são tratados como projetos isolados.

Manter a verificação após a assinatura do contrato

A due diligence não é um dossier em PDF feito uma única vez. Estabeleça, no mínimo, uma rotina de revisão periódica e verificações baseadas em eventos. Os gatilhos incluem novos subprocessadores, alteração do fornecedor do modelo, novas funcionalidades do produto, mudança nos locais de armazenamento, incidentes de segurança, expiração de certificações ou alterações numa decisão de adequação. A lista atualizada de subprocessadores e as versões contratuais relevantes devem ser arquivadas com data para garantir a rastreabilidade.

O critério prático é simples: a sua equipa consegue explicar, para cada fluxo de dados relevante, quem processa o quê, por que razão, onde ocorre, por quanto tempo os dados permanecem, que medidas de proteção se aplicam e como funciona o plano de saída? Se estas respostas estiverem comprovadas, uma promessa genérica de privacidade transforma-se numa decisão de contratação sólida. Se componentes centrais continuarem desconhecidos, o chatbot não deve operar com dados reais de visitantes.