Registro das operações de tratamento (ROPA)
API do QR Branding — Art. 30 do RGPD
| Campo | Valor |
|---|---|
| Controlador | QR Branding (Quartzon) |
| Data | 2026-03-08 |
| Versão | 1.0 |
Atividade 1: Geração de QR codes
| Campo | Descrição |
|---|---|
| Nome | Geração de QR codes personalizados |
| Controlador | QR Branding |
| Finalidade | Gerar imagens de QR (PNG/SVG/PDF/Base64) a partir do conteúdo e da configuração fornecidos pelo usuário |
| Base legal | Execução de contrato — Art. 6(1)(b) |
| Categorias de titulares | Usuários da API (desenvolvedores, empresas) e contatos incluídos em vCards |
| Categorias de dados | URLs, texto livre, credenciais de Wi-Fi (SSID/senha), dados de contato em vCard (nome, e-mail, telefone, endereço, organização), geolocalização, endereços de e-mail, números de telefone |
| Destinatários | Nenhum: o tratamento é exclusivamente interno; o resultado é retornado ao usuário |
| Transferências internacionais | Não: tratamento no Azure (região de hospedagem) |
| Prazos de exclusão | Imediato: os dados são tratados em memória e descartados após a resposta HTTP |
| Medidas de segurança | TLS 1.2+, validação de entradas (OWASP), proteção contra SSRF, remoção de metadados EXIF, limitação de requisições, autenticação da RapidAPI, anonimização de IP nos logs |
Atividade 2A: QR codes gerados com IA com as contas do QR Branding nos provedores
| Campo | Descrição |
|---|---|
| Nome | Geração de designs de QR com inteligência artificial, com as contas próprias do QR Branding nos provedores de LLM |
| Escopo | O designer com IA em qr-branding.com e o endpoint gerenciado do marketplace (POST /api/qr/ai/generate-managed) |
| Controlador | QR Branding |
| Finalidade | Gerar uma configuração de design de QR a partir de um prompt em linguagem natural |
| Base legal | Execução de contrato — Art. 6(1)(b) |
| Modelo de chave de API | Chaves de API próprias do QR Branding. Cada requisição passa por uma cadeia interna de provedores de fallback (Groq, Google Gemini, OpenAI): se um provedor falhar, tenta-se o seguinte |
| Categorias de titulares | Usuários do site qr-branding.com e usuários da API |
| Categorias de dados | Prompt de design (texto livre) e parâmetros de geração (estilo predefinido, criatividade, escaneabilidade estrita). O conteúdo do QR não é enviado ao LLM |
| Destinatários | O provedor de LLM que atende a requisição na cadeia de fallback |
| Operadores | Groq, Inc., Google LLC (Gemini) e OpenAI, OpCo, LLC, conforme a página de suboperadores |
| Transferências internacionais | Sim: os três provedores estão localizados nos EUA. A transferência se baseia nos termos de tratamento de dados de cada provedor, conforme a página de suboperadores |
| Prazos de exclusão | O texto do prompt é tratado em memória e não é armazenado pelo QR Branding. A configuração de design gerada pode ser mantida no cache de prompts por até 30 dias, sob uma chave derivada de um hash SHA-256 do prompt e dos parâmetros. A retenção pelo provedor é regida pelos seus próprios termos |
| Medidas de segurança | Delimitadores de prompt, instruções anti-vazamento, anulação dos campos de URL/base64, sanitização de HTML, limite de tokens de saída em cada chamada ao LLM, limites de tamanho da resposta (1MB), ocultação de chaves de API nos logs (SanitizeForLog). Nenhum e-mail, dado de cobrança, endereço IP ou identificador do cliente é enviado ao provedor |
Atividade 2B: QR codes gerados com IA com a chave própria do cliente (BYOK)
| Campo | Descrição |
|---|---|
| Nome | Geração de designs de QR com inteligência artificial, com a chave de API de LLM própria do cliente |
| Escopo | O endpoint do marketplace POST /api/qr/ai/generate |
| Controlador | QR Branding (tratamento do prompt e renderização) |
| Finalidade | Gerar uma configuração de design de QR a partir de um prompt em linguagem natural |
| Base legal | Execução de contrato — Art. 6(1)(b) |
| Modelo de chave de API | BYOK (Bring Your Own Key): o cliente fornece a sua própria chave de API do provedor de LLM (llmApiKey) em cada requisição e escolhe o provedor: OpenAI, Anthropic, Google, Mistral, Cohere, Groq, xAI, DeepSeek ou Qwen, ou o seu próprio endpoint compatível com OpenAI (local) |
| Categorias de titulares | Usuários da API |
| Categorias de dados | Prompt de design (texto livre), chave de API do cliente (transitória, não armazenada), conteúdo do QR (não enviado ao LLM) |
| Destinatários | O provedor de LLM (ou o endpoint próprio do cliente) selecionado pelo usuário, usando a chave de API do próprio usuário |
| Operadores | Nenhum nesta atividade: o QR Branding atua como intermediário técnico. A relação contratual com o provedor de LLM é direta entre o cliente e o provedor |
| Transferências internacionais | A transferência de dados ao provedor de LLM é responsabilidade do cliente, que mantém a sua própria relação contratual com o provedor. O QR Branding apenas encaminha o prompt no nível técnico |
| Prazos de exclusão | O texto do prompt é tratado em memória e não é armazenado. A configuração de design gerada pode ser mantida no cache de prompts por até 30 dias, sob uma chave derivada de um hash SHA-256 do prompt e dos parâmetros. A chave de API do cliente não é armazenada nem registrada em logs |
| Medidas de segurança | Delimitadores de prompt, instruções anti-vazamento, anulação dos campos de URL/base64, sanitização de HTML, limite de tokens de saída em cada chamada ao LLM, limites de tamanho da resposta (1MB), ocultação de chaves de API nos logs (SanitizeForLog) |
Atividade 3: Limitação de requisições e prevenção de abusos
| Campo | Descrição |
|---|---|
| Nome | Controle da frequência de requisições |
| Controlador | QR Branding |
| Finalidade | Prevenir abusos e proteger a disponibilidade do serviço e os custos operacionais |
| Base legal | Interesse legítimo — Art. 6(1)(f) |
| Interesse legítimo | Proteger a infraestrutura e a disponibilidade do serviço para todos os usuários |
| Categorias de titulares | Todos os usuários da API |
| Categorias de dados | Identificador da RapidAPI (pseudônimo), identificador da assinatura, endereço IP (anonimizado) |
| Destinatários | Nenhum: tratamento interno |
| Transferências internacionais | Não |
| Prazos de exclusão | 2 minutos (janela deslizante em memória com remoção automática) |
| Medidas de segurança | Dados mantidos em memória volátil (não persistidos), anonimização de IP (último octeto), limite de 50.000 IPs rastreados, limpeza periódica a cada 2 minutos |
Atividade 4: Telemetria e diagnóstico
| Campo | Descrição |
|---|---|
| Nome | Monitoramento de desempenho e diagnóstico de erros |
| Controlador | QR Branding |
| Finalidade | Manter o serviço confiável, diagnosticar erros e monitorar o desempenho |
| Base legal | Interesse legítimo — Art. 6(1)(f) |
| Interesse legítimo | Garantir a estabilidade operacional e uma resposta rápida a incidentes |
| Categorias de titulares | Todos os usuários da API |
| Categorias de dados | Caminhos das requisições (sem conteúdo de QR), códigos de status HTTP, tempos de resposta, erros (sem dados pessoais identificáveis), métricas de desempenho |
| Destinatários | Microsoft (Azure Application Insights) como operador |
| Transferências internacionais | Possíveis, conforme a região configurada do Application Insights |
| Prazos de exclusão | 90 dias (configuração padrão do Application Insights) |
| Medidas de segurança | Mensagens de erro sem dados pessoais identificáveis, ocultação de chaves de API (SanitizeForLog), anonimização de IP, nenhum registro em logs de conteúdo de QR nem de prompts de IA |
Atividade 5: Autenticação da API
| Campo | Descrição |
|---|---|
| Nome | Verificação de autenticação da RapidAPI |
| Controlador | QR Branding (middleware), RapidAPI (plataforma) |
| Finalidade | Validar que as requisições vêm do proxy autorizado da RapidAPI |
| Base legal | Interesse legítimo — Art. 6(1)(f) |
| Categorias de titulares | Todos os usuários da API |
| Categorias de dados | Cabeçalho X-RapidAPI-Proxy-Secret (um secret do servidor, não um dado pessoal) |
| Destinatários | Nenhum |
| Transferências internacionais | Não |
| Prazos de exclusão | Não se aplica: o secret é verificado em memória e não é armazenado |
| Medidas de segurança | Comparação no middleware, secret armazenado nas App Settings do Azure (criptografado), nunca exposto em logs nem em respostas |
Resumo dos operadores
| Operador | Atividade | DPA | Localização |
|---|---|---|---|
| Microsoft Azure | Hospedagem, Application Insights | ✅ OST/DPA padrão | UE/EUA (configurável) |
| RapidAPI | Marketplace, cobrança, autenticação | ✅ Termos da plataforma | EUA |
| Groq | Geração com IA com as contas do QR Branding (Atividade 2A) | ⚠️ Termos de tratamento de dados do provedor, pendente de confirmação | EUA |
| Google (Gemini) | Geração com IA com as contas do QR Branding (Atividade 2A) | ⚠️ Termos de tratamento de dados do provedor, pendente de confirmação | EUA |
| OpenAI | Geração com IA com as contas do QR Branding (Atividade 2A) | ⚠️ Termos de tratamento de dados do provedor, pendente de confirmação | EUA |
Observação sobre os provedores de LLM: Groq, Google (Gemini) e OpenAI são operadores do QR Branding somente na geração com IA com as contas próprias do QR Branding (Atividade 2A). No endpoint BYOK (Atividade 2B), nenhum provedor de LLM é operador do QR Branding: o cliente fornece a sua própria chave de API, e a relação contratual e o DPA com o provedor que ele escolher são responsabilidade direta do cliente.
Documento gerado em 2026-03-08. Atualize-o sempre que qualquer atividade de tratamento mudar.