Análise da base legal do tratamento de dados
API do QR Branding — Art. 6 do RGPD
| Campo | Valor |
|---|---|
| Controlador | QR Branding (Quartzon) |
| Data | 2026-03-08 |
| Versão | 1.0 |
1. Princípio da licitude (Art. 6)
Todo tratamento de dados pessoais deve se apoiar em pelo menos uma das bases legais do Art. 6(1) do RGPD. A seguir, analisamos cada atividade de tratamento do QR Branding e a base legal correspondente.
2. Análise por atividade de tratamento
2.1 Geração de QR codes que contêm dados pessoais
| Aspecto | Análise |
|---|---|
| Atividade | O usuário envia um conteúdo de QR que pode incluir dados pessoais (um vCard com nome, e-mail, telefone e endereço; geolocalização; endereços de e-mail) |
| Base legal | Art. 6(1)(b) — Execução de contrato |
| Justificativa | O tratamento é necessário para prestar o serviço que o usuário contratou pela RapidAPI. Sem tratar o conteúdo, não é possível gerar o QR code solicitado |
| Proporcionalidade | Mínima: somente o conteúdo estritamente necessário é tratado, em memória, sem armazenamento |
| Alternativa menos intrusiva | Nenhuma: o conteúdo do QR SÃO os dados a serem codificados |
2.2 QR codes gerados com IA
A geração com IA funciona em duas modalidades:
- Contas próprias do QR Branding (o designer com IA em qr-branding.com e o endpoint gerenciado
POST /api/qr/ai/generate-managed): o QR Branding envia o prompt de design, com as suas próprias chaves de API, a um provedor de LLM da sua cadeia interna de fallback (Groq, Google Gemini, OpenAI). Esses provedores atuam como operadores do QR Branding e constam na página de suboperadores. - BYOK (Bring Your Own Key) (o endpoint
POST /api/qr/ai/generate): o cliente fornece a sua própria chave de API e escolhe o provedor; o QR Branding não usa as suas contas próprias nessas requisições.
| Aspecto | Análise |
|---|---|
| Atividade | O usuário envia um prompt de design. O QR Branding encaminha o prompt a um provedor de LLM: com as suas próprias chaves (site e endpoint gerenciado) ou com a chave do cliente (llmApiKey, endpoint BYOK) |
| Modelo | Contas próprias do QR Branding com Groq, Google (Gemini) e OpenAI, ou BYOK (Bring Your Own Key) com o provedor escolhido pelo cliente |
| Base legal | Art. 6(1)(b) — Execução de contrato |
| Justificativa | O usuário solicita expressamente um design gerado com IA: no site e no endpoint gerenciado, ao acionar uma geração com IA; no endpoint BYOK, também ao selecionar o provedor e fornecer a sua própria chave de API. O tratamento é necessário para atender a essa solicitação específica |
| Proporcionalidade | Somente o prompt de design e os parâmetros de geração são enviados ao LLM. O conteúdo do QR, os endereços IP e os dados de identificação NUNCA são transmitidos. No endpoint BYOK, a chave de API do cliente não é armazenada nem registrada em logs |
| Observação | O usuário escolhe ativamente usar a geração com IA e o prompt que envia. No endpoint BYOK, ele também escolhe o provedor de LLM e fornece a sua própria chave de API, e a relação com o provedor de LLM é direta entre o cliente e o provedor |
2.3 Limitação de requisições
| Aspecto | Análise |
|---|---|
| Atividade | Contagem de requisições por identificador (usuário da RapidAPI, ID da assinatura, IP anonimizado) para limitar a frequência de uso |
| Base legal | Art. 6(1)(f) — Interesse legítimo |
| Interesse legítimo | Proteger a disponibilidade do serviço para todos os usuários e prevenir abusos e custos excessivos |
| Teste de ponderação | |
| — Interesse do controlador | Alto: sem limitação de requisições, um único usuário poderia esgotar os recursos ou gerar custos proibitivos |
| — Impacto sobre o titular | Mínimo: apenas um identificador pseudônimo é usado para contar as requisições, os dados ficam em memória volátil (2 min) e os endereços IP são anonimizados |
| — Expectativa razoável | Sim: os usuários de APIs esperam limites de requisições como prática padrão do setor |
| — Salvaguardas | Dados efêmeros (2 min), anonimização de IP, limite de rastreamento (50 mil IPs), nenhum registro de identificadores em logs |
| Resultado | O interesse legítimo prevalece claramente, dado o impacto mínimo sobre o titular |
2.4 Telemetria e diagnóstico (Application Insights)
| Aspecto | Análise |
|---|---|
| Atividade | Coleta de métricas de desempenho, erros e metadados das requisições (sem dados pessoais identificáveis) |
| Base legal | Art. 6(1)(f) — Interesse legítimo |
| Interesse legítimo | Manter o serviço confiável e disponível e diagnosticar problemas rapidamente |
| Teste de ponderação | |
| — Interesse do controlador | Alto: sem telemetria, não é possível detectar nem resolver incidentes |
| — Impacto sobre o titular | Mínimo: dados pessoais identificáveis removidos das mensagens de erro, chaves de API ocultadas, endereços IP anonimizados |
| — Expectativa razoável | Sim: o monitoramento é prática padrão em serviços de nuvem |
| — Salvaguardas | Retenção de 90 dias, logs sem dados pessoais identificáveis, anonimização de IP, ocultação de chaves de API |
| Resultado | O interesse legítimo prevalece claramente |
2.5 Autenticação da RapidAPI
| Aspecto | Análise |
|---|---|
| Atividade | Verificação do cabeçalho X-RapidAPI-Proxy-Secret em cada requisição |
| Base legal | Art. 6(1)(f) — Interesse legítimo |
| Justificativa | Proteger o serviço contra acessos não autorizados |
| Observação | O secret é um dado do servidor, não do usuário. Nesta etapa, nenhum dado pessoal é tratado |
3. Bases legais NÃO utilizadas
| Base legal | Art. | Por que não é utilizada? |
|---|---|---|
| Consentimento | Art. 6(1)(a) | Não se coleta consentimento expresso. Ele não é necessário: o tratamento se baseia no contrato e no interesse legítimo. Basear-se no consentimento criaria obrigações adicionais (possibilidade de revogação) sem nenhum benefício |
| Obrigação legal | Art. 6(1)(c) | Nenhuma obrigação legal exige o tratamento desses dados |
| Interesses vitais | Art. 6(1)(d) | Não se aplica: o serviço não trata dados para proteger interesses vitais |
| Interesse público | Art. 6(1)(e) | Não se aplica: trata-se de um serviço comercial privado |
4. Categorias especiais de dados (Art. 9)
O QR Branding não solicita nem exige categorias especiais de dados pessoais (origem étnica, saúde, orientação sexual etc.).
No entanto, o usuário poderia incluir esses dados no conteúdo do QR (por exemplo, um QR code com dados médicos). Nesse caso:
- O QR Branding atua como operador técnico que codifica os dados sem interpretá-los.
- A responsabilidade pelo tratamento das categorias especiais recai sobre o usuário que decide incluí-las.
- A base legal nesse cenário seria o consentimento explícito do titular, que o usuário deve obter antes de codificar os dados.
- O QR Branding não armazena esses dados e os descarta imediatamente após a geração.
5. Dados de crianças (Art. 8)
- O QR Branding é um serviço de API B2B/B2C voltado a desenvolvedores e empresas.
- Não se destina a menores de 16 anos.
- Nenhum dado de idade é coletado e nenhuma verificação de idade é realizada.
- Se um usuário incluir dados de crianças no conteúdo do QR, a responsabilidade por obter o consentimento dos pais ou responsáveis é do usuário.
6. Transferências internacionais (Art. 44-49)
| Destino | Base legal da transferência | Provedor |
|---|---|---|
| UE/EUA (Azure) | Online Services Terms + CCT | Microsoft Azure |
| EUA | Termos da plataforma | RapidAPI |
| EUA | Termos de tratamento de dados de cada provedor (ver a página de suboperadores) | Groq, Google (Gemini), OpenAI: geração com IA com as contas do QR Branding |
Observação sobre os provedores de LLM: com as contas próprias do QR Branding (o site e o endpoint gerenciado), os prompts de design são transferidos para Groq, Google (Gemini) ou OpenAI, que atuam como operadores do QR Branding. No endpoint BYOK, os prompts são transferidos ao provedor escolhido pelo cliente (OpenAI, Anthropic, Google, Mistral, Cohere, Groq, xAI, DeepSeek ou Qwen, ou o seu próprio endpoint compatível com OpenAI) usando a chave de API do próprio cliente. A responsabilidade por essa transferência é do cliente, que mantém uma relação contratual direta com o provedor; o QR Branding atua como intermediário técnico.
O uso do endpoint padrão de geração de QR não envolve nenhuma transferência a provedores de LLM (o tratamento ocorre exclusivamente no Azure).
7. Revisão
Esta análise da base legal deve ser revisada:
- Quando forem adicionadas novas atividades de tratamento
- Quando mudarem os dados tratados pelas atividades existentes
- Quando mudarem as políticas dos provedores de LLM
- Pelo menos uma vez por ano
Documento gerado em 2026-03-08.