Relatório de impacto à proteção de dados (RIPD/DPIA)
API do QR Branding — recursos de IA
| Campo | Valor |
|---|---|
| Data | 2026-03-08 |
| Controlador | QR Branding (Quartzon) |
| Versão | 1.0 |
| Situação | Aprovado |
| Próxima revisão | 2026-09-08 |
1. Descrição do tratamento
1.1 Natureza do tratamento
O QR Branding oferece a geração de QR codes com IA em duas modalidades:
- Com as contas próprias do QR Branding nos provedores de LLM: o designer com IA em qr-branding.com e o endpoint gerenciado do marketplace (
POST /api/qr/ai/generate-managed). Uma cadeia interna de provedores de fallback (Groq, Google Gemini, OpenAI) atende cada requisição. - Com a chave própria do cliente (BYOK): o endpoint do marketplace
POST /api/qr/ai/generate. O cliente fornece a sua própria chave de API e escolhe o provedor (OpenAI, Anthropic, Google, Mistral, Cohere, Groq, xAI, DeepSeek ou Qwen, ou o seu próprio endpoint compatível com OpenAI).
Nas duas modalidades, o usuário envia um prompt de design em linguagem natural (por exemplo, "QR code azul moderno para uma empresa de tecnologia") junto com o conteúdo do QR (URL, texto, vCard etc.). O sistema:
- Envia somente o prompt de design e os parâmetros de geração a um provedor externo de LLM: o que atende a requisição na cadeia de fallback do QR Branding ou o selecionado pelo usuário (BYOK).
- Recebe do LLM uma configuração de design em JSON.
- Gera o QR code com o conteúdo fornecido e o design sugerido.
- Retorna a imagem do QR ao usuário.
1.2 Escopo
- Dados tratados: prompts de design (texto livre), parâmetros de geração (estilo predefinido, criatividade, escaneabilidade estrita), conteúdo do QR (URLs, texto, dados de contato em vCard, credenciais de Wi-Fi, geolocalização), a chave de API do cliente (somente BYOK, transitória).
- Volume estimado: até 15 requisições de IA por minuto por IP, 100 gerações por minuto no total.
- Titulares afetados: usuários do site qr-branding.com, usuários da API (desenvolvedores, empresas) e, indiretamente, as pessoas cujos dados aparecem no conteúdo do QR (contatos em vCard).
- Área geográfica: global (API pública no RapidAPI Marketplace).
1.3 Contexto
- Serviço stateless: não há banco de dados e nenhum conteúdo de QR é persistido.
- Contas próprias do QR Branding (site e endpoint gerenciado): o QR Branding mantém chaves de API próprias com Groq, Google (Gemini) e OpenAI, que atuam como seus operadores e constam na página de suboperadores. Nenhum e-mail, dado de cobrança, endereço IP ou identificador do cliente é enviado a eles.
- Modelo BYOK (Bring Your Own Key) (
POST /api/qr/ai/generate): o cliente fornece a sua própria chave de API em cada requisição; o QR Branding não usa as suas contas próprias nessas requisições. - O conteúdo do QR nunca é enviado aos provedores de IA; somente o prompt de design é enviado.
- Os campos sensíveis gerados pelo LLM (URLs, base64) são anulados antes da renderização.
- O serviço roda no Azure Functions (Consumption Plan).
- No endpoint BYOK, a relação contratual com o provedor de LLM é direta entre o cliente e o provedor.
1.4 Finalidade
Permitir que os usuários gerem designs de QR personalizados a partir de descrições em linguagem natural, eliminando a necessidade de configurar parâmetros manualmente.
2. Necessidade e proporcionalidade
2.1 Base legal
Execução de contrato (Art. 6(1)(b) do RGPD): o tratamento é necessário para prestar o serviço específico solicitado pelo usuário.
2.2 Minimização de dados
| Princípio | Implementação |
|---|---|
| Somente os dados necessários | Somente o prompt é enviado ao LLM, não o conteúdo do QR |
| Sem armazenamento | Tratamento em memória; o texto do prompt e o conteúdo do QR são descartados após a resposta HTTP. Somente a configuração de design gerada pode ser mantida em cache por até 30 dias, sob uma chave derivada de um hash SHA-256 do prompt e dos parâmetros |
| Sem criação de perfis | Não são criados perfis de usuários nem históricos de requisições |
| Anonimização | Endereços IP anonimizados nos logs (último octeto mascarado) |
| Segregação | Conteúdo do QR e prompt de IA mantidos separados no fluxo de dados |
2.3 Proporcionalidade
O tratamento é proporcional porque:
- O usuário escolhe ativamente usar o recurso de IA (endpoint separado).
- No endpoint BYOK, o usuário seleciona o provedor de LLM; no site e no endpoint gerenciado, o provedor é um dos operadores listados na página de suboperadores.
- Somente o prompt de design é transferido (não os dados pessoais do conteúdo do QR).
- Não há alternativa menos intrusiva para gerar designs a partir de linguagem natural.
3. Identificação e avaliação de riscos
3.1 Riscos identificados
| # | Risco | Probabilidade | Impacto | Nível | Mitigação |
|---|---|---|---|---|---|
| R1 | Injeção de prompt: o usuário injeta instruções maliciosas no prompt | Média | Médio | Médio | Delimitadores <user_request>, instruções anti-vazamento no prompt de sistema, campos de URL/base64 anulados após o LLM |
| R2 | Dados pessoais nos prompts: o usuário inclui dados pessoais na descrição do design | Média | Baixo | Baixo | Não armazenamos o texto dos prompts (o cache guarda somente o design gerado sob uma chave derivada de um hash); o prompt é enviado sem nenhum identificador do usuário; política de uso documentada |
| R3 | Exfiltração do prompt de sistema: um atacante extrai as instruções do sistema | Baixa | Baixo | Baixo | Rodapé anti-vazamento no prompt de sistema, saída sanitizada (tags HTML removidas) |
| R4 | Transferência internacional: prompts encaminhados a provedores fora do EEE | Média | Baixo | Baixo | Contas do QR Branding: Groq, Google e OpenAI (EUA) atuam como operadores conforme os termos de tratamento de dados de cada provedor; somente o prompt de design e os parâmetros são enviados. BYOK: o cliente tem uma relação direta com o provedor e o seu próprio DPA; o QR Branding atua apenas como intermediário técnico. Informação na Política de Privacidade e na página de suboperadores |
| R5 | Retenção pelo provedor de LLM: o provedor retém dados segundo as suas próprias políticas | Média | Baixo | Baixo | Contas do QR Branding: regida pelos termos de tratamento de dados de cada provedor com o QR Branding. BYOK: responsabilidade do cliente segundo os seus próprios termos com o provedor |
| R6 | Resposta do LLM com conteúdo malicioso: XSS, URLs maliciosas | Média | Médio | Médio | Regex de sanitização de HTML com timeout, campos de URL/base64 anulados, MaxDepth=32 na desserialização |
| R7 | Denial of wallet: abuso do endpoint de IA para inflar os custos | Média | Alto | Alto | Limitação de requisições (15 de IA/min por IP, 100/min no total), RenderThrottle com semáforo, functionTimeout 1:30 |
| R8 | Vazamento de chaves de API nos logs | Baixa | Alto | Médio | SanitizeForLog() oculta os padrões de chaves de API, mensagens de erro sem dados pessoais |
3.2 Mapa do fluxo de dados
User → qr-branding.com or RapidAPI Proxy → Azure Functions
↓
[Design prompt + parameters only]
↓
LLM provider (QR Branding's fallback chain,
or the user's choice on BYOK)
↓
[Design JSON config]
↓
QR Rendering (SkiaSharp)
+ QR content (never leaves the server)
↓
QR image → User
4. Medidas de mitigação
4.1 Medidas técnicas implementadas
| Medida | Risco mitigado | Situação |
|---|---|---|
Delimitadores de prompt (<user_request>) | R1 | ✅ Implementada |
| Rodapé anti-vazamento no prompt de sistema | R1, R3 | ✅ Implementada |
| Anulação dos campos de URL/base64 do LLM | R1, R6 | ✅ Implementada |
| Regex de sanitização de HTML com timeout (3s) | R6 | ✅ Implementada |
| MaxDepth=32 no JsonSerializer | R6 | ✅ Implementada |
| Limitação de requisições de IA (15/min por IP, 100/min no total) | R7 | ✅ Implementada |
| RenderThrottle (semáforo, 4 simultâneas) | R7 | ✅ Implementada |
| functionTimeout 1:30 | R7 | ✅ Implementada |
| SanitizeForLog(): ocultação de chaves de API | R8 | ✅ Implementada |
| Anonimização de IP (último octeto) | R2 | ✅ Implementada |
| Mensagens de erro sem dados pessoais | R2 | ✅ Implementada |
| Limite de tokens de saída em cada chamada ao LLM | R7 | ✅ Implementada |
| Content-Length + verificação do tamanho após a leitura (1MB) | R7 | ✅ Implementada |
| Separação do systemInstruction do Google | R1 | ✅ Implementada |
4.2 Medidas organizacionais
| Medida | Risco mitigado | Situação |
|---|---|---|
| Política de Privacidade publicada | R4, R5 | ✅ Implementada |
| Divulgação dos provedores de LLM na documentação e na página de suboperadores | R4 | ✅ Implementada |
| DPAs com os provedores de LLM usados com as contas do QR Branding (Groq, Google, OpenAI) | R4, R5 | ⚠️ Pendente de confirmação |
| DPAs com o provedor de LLM no endpoint BYOK | R5 | Responsabilidade do cliente |
| Procedimento de atendimento aos direitos dos titulares documentado | Geral | ✅ Documentado |
| Plano de resposta a incidentes | Geral | ✅ Documentado |
5. Conclusão
5.1 Risco residual
Com todas as medidas técnicas e organizacionais implementadas, o risco residual é avaliado como BAIXO:
- O tratamento é stateless: nem o conteúdo do QR nem o texto do prompt são persistidos (o cache de prompts guarda somente designs gerados sob uma chave derivada de um hash).
- O conteúdo do QR (potencialmente sensível) nunca sai da infraestrutura do Azure.
- Somente os prompts de design (que raramente contêm dados pessoais) são transferidos a terceiros.
- Todas as mitigações técnicas da megaauditoria estão implementadas e verificadas.
5.2 Decisão
✅ O tratamento pode prosseguir com as medidas atuais.
Não é necessária a consulta prévia à autoridade de controle (Art. 36 do RGPD), pois o risco residual é baixo.
5.3 Revisão
Este RIPD será revisado:
- Pelo menos a cada 6 meses.
- Quando forem adicionados novos provedores de LLM.
- Quando mudar o fluxo de dados do endpoint de IA.
- Quando forem introduzidos novos tipos de conteúdo de QR que possam conter dados sensíveis.
Documento gerado em 2026-03-08. Próxima revisão programada: 2026-09-08.