Em 60 segundos
O que um gestor, um jurídico ou um time de TI precisa saber antes de confiar a carteira de clientes a um CRM.
🔐Cada corretor só vê o que é dele
O isolamento é aplicado no banco de dados, não só na tela. Mesmo um erro de interface não consegue expor o lead de outro usuário: o banco nega.
🧱Navegador sem brechas de script
Política CSP bloqueante em produção: nenhum script inline é executado. É o controle anti-XSS mais forte que existe — e a maioria dos SaaS não o tem.
🤖Só o app oficial conversa com o backend
Atestação de cliente (App Check) em bloqueio no banco, nas APIs, no WhatsApp e no login. Bots e scripts falsos recebem 401 antes de qualquer coisa.
🗝️Segredos nunca no código
Chaves de IA, tokens e credenciais vivem no Secret Manager e são cifrados com AES-256-GCM. Nada disso chega ao navegador nem a um log.
⚖️LGPD que executa
Exportação, correção, pseudonimização e exclusão funcionam — com identidade verificada, simulação de impacto e trilha de auditoria. Encarregado (DPO) nomeado e publicado.
🇧🇷Dados no Brasil
Banco de dados hospedado em São Paulo (Google Cloud southamerica-east1), com backup contínuo e recuperação pontual.
Defesa em 7 camadas
Camadas independentes que se reforçam. Para chegar a um dado sensível, uma requisição precisa atravessar todas elas — e cada uma foi verificada isoladamente.
Navegador
CSP bloqueante (sem script inline, sem eval), escape de todo dado de terceiros na renderização, cofre de chaves com WebCrypto.
Atestação de cliente
App Check com reCAPTCHA Enterprise em bloqueio: requisição sem atestado válido nem chega à autenticação.
Identidade
Login Google (OAuth) com tokens JWT assinados e validados no servidor; sem cookies de sessão; controle de sessão e de dispositivos por licença.
Autorização
Licença valida status, plano, papel e validade; rotas administrativas exigem papel de admin conferido no backend; escrita na licença é proibida ao navegador.
Banco de dados
Regras default-deny: acesso por dono, whitelist de campos, coleções sensíveis somente servidor, limites de tamanho, sem exclusão física.
Backend
APIs isoladas por domínio, segredos no Secret Manager, rate limiting em bloqueio, webhooks com assinatura HMAC-SHA256 e idempotência.
Governança
Seis trilhas de auditoria, programa LGPD operacional, DPO, kill-switches por superfície, backup com recuperação pontual.
Checklist de controles ativos
Cada item abaixo está ligado em produção e foi verificado diretamente — não é intenção, é estado.
unsafe-inline/eval679 handlers inline migrados → 0. Validado byte a byte em produção.ImobPilot × prática comum do mercado
O que costuma existir em CRMs e SaaS do segmento — e o que o ImobPilot faz no lugar.
unsafe-inline, que anula a proteção contra XSS.“Prática comum” descreve padrões de arquitetura amplamente documentados no setor; não é avaliação de nenhum produto nomeado. As afirmações sobre o ImobPilot vêm de verificação direta em produção.
Identidade e acesso
🔑Login Google, sem senha própria
Autenticação via Google OAuth (Firebase Auth). O ImobPilot não armazena senhas — não há senha para vazar. O Google emite ID Tokens JWT assinados, que o backend valida criptograficamente a cada chamada.
🍪Sem cookies de sessão
O token viaja como Authorization: Bearer. Um site malicioso aberto em outra aba não consegue obtê-lo nem reutilizá-lo — a classe inteira de ataques CSRF fica neutralizada por desenho.
📱Controle de sessão e dispositivos
Cada entrada é validada no backend e registrada com identificador aleatório (sem fingerprinting). O limite de dispositivos por licença — padrão seguro = 1 — impede o compartilhamento de contas.
🛂Licença e papel conferidos no servidor
Status (active), plano, papel e validade são verificados antes de liberar o CRM. Rotas administrativas exigem papel de admin no backend; a tentativa não autorizada recebe 403 e vira evento auditado.
Fluxo de entrada
- Login Google concluído → token JWT emitido.
- Licença validada (status, plano, papel, validade).
- Sessão e dispositivo validados no backend.
- Aceite LGPD vigente conferido (bloqueia se houver versão nova).
- Só então o CRM é liberado.
Banco de dados blindado
O coração do modelo de acesso. As regras do banco são a última linha de defesa — e aqui elas são a primeira.
👤Acesso por dono
Leads, imóveis, visitas, comissões, agentes e registros LGPD só são lidos ou gravados pelo próprio dono. A identidade vem do token, não de um campo enviado pelo cliente.
📋Whitelist de campos
Cada escrita em lead é validada contra uma lista fechada de campos. Campo desconhecido, dono alterado ou identificador imutável modificado → a gravação inteira é rejeitada.
🚫Somente-servidor
Conversas de WhatsApp, sessões, leads de Meta Ads, cobrança, eventos de segurança e auditoria LGPD são invisíveis ao navegador. Só o backend isolado os acessa.
Padrões aplicados
| Padrão | O que garante |
|---|---|
| Default-deny explícito | Tudo que não foi liberado nominalmente é negado. Não existe “acesso por esquecimento”. |
| Owner-scoped | Leitura e escrita condicionadas a ownerEmail == identidade do token; dono imutável após a criação. |
| Campos imutáveis | Identificadores, número de controle e datas de criação não podem ser alterados depois de gravados. |
| Caps de tamanho | Limites por campo (nome, e-mail, telefone, observações, tags) impedem abuso de armazenamento e payloads anômalos. |
| Sem delete físico | Leads são arquivados, nunca apagados pelo navegador — proteção contra erro humano e contra scripts maliciosos. |
| Leitura administrativa restrita | Relatórios de uso e telemetria só para papel de admin, conferido na regra. |
Backend isolado
Cada domínio de negócio roda em uma API própria, com seus próprios guardas. Um problema em uma não contamina as outras.
| API | Responsabilidade | Guardas ativos |
|---|---|---|
| Agentes de IA | Configuração e execução assistida | App Check · rate limit · papel admin · gate de dispositivo |
| Cobrança | Checkout e status de assinatura | App Check · rate limit em bloqueio · webhook HMAC |
| LGPD | Direitos do titular e processamento admin | App Check · rate limit em bloqueio · identidade verificada · papel admin |
| Google Calendar | OAuth e agenda | App Check · rate limit · tokens cifrados |
| Segurança | Validação de sessão e dispositivo | App Check · rate limit · só hashes |
| Meta Ads | OAuth e recepção de leads | Webhook autenticado por HMAC-SHA256 |
| Telemetria CSP | Coleta de violações de política | Limite de tamanho e de instâncias |
🧰Privilégio onde ele pertence
Somente o backend tem credenciais administrativas sobre o banco. Por isso toda coleção sensível é somente-servidor e toda autorização vive em código revisado, não no navegador.
⏱️Rate limiting em bloqueio
Limites por IP e por usuário nas rotas de cobrança, status e administração. Resposta 429 genérica — sem revelar o limite ao atacante. Cada bloqueio vira evento auditado (só hashes).
Atestação de cliente (App Check)
Garante que quem fala com o backend é o aplicativo oficial rodando em um navegador real — não um script, um bot ou uma cópia adulterada.
🛡️Em bloqueio nas 4 superfícies
Banco de dados, 5 APIs de navegador, API do WhatsApp e login. Requisição sem atestado válido recebe 401 antes mesmo de chegar à autenticação.
🧪Ativação com prova
Cada superfície foi ligada por etapa: baseline de 24h com ≈99% de atestados válidos, sonda negativa (requisição sem token → bloqueio) e janela de aceitação com zero rejeições de tráfego legítimo.
🏢reCAPTCHA Enterprise
Provedor de atestação de grau corporativo. Apenas a chave pública do site vai ao navegador; nenhum segredo ou token de depuração existe no código.
🎚️Reversível por superfície
Cada camada tem seu próprio interruptor (off / monitor / bloqueio). Em caso de incidente com o provedor, a reversão leva minutos — sem tocar no produto.
Navegador & anti-XSS
Cross-site scripting é o ataque nº 1 contra aplicações web. O ImobPilot o combate em duas frentes que se somam.
🧱CSP bloqueante em produção
Desde 10/08/2026 o cabeçalho Content-Security-Policy servido ao vivo proíbe scripts inline e eval. Mesmo que um dado malicioso chegasse à página, o navegador se recusa a executá-lo.
🧼Escape em toda renderização
Dados digitados, recebidos do WhatsApp ou de anúncios Meta são transformados em texto inerte antes de ir à tela. Normalização também na gravação.
O tamanho da entrega
| Indicador | Antes | Hoje |
|---|---|---|
Handlers inline on*= no código | 679 | 0 |
| Scripts inline executáveis | 6 | 0 |
eval / new Function / timers por string | 0 | 0 |
Atributos on*= no DOM real das 6 páginas públicas | — | 0 |
- Validação independente na origem
https://imobpilot.com.br: cabeçalho bloqueante idêntico à fonte (drift zero) e 14 arquivos de primeira parte conferidos por SHA-256, byte a byte. - Arquitetura de ações fechada: toda ação de interface resolve por um mapa allowlist explícito — nunca por nome dinâmico,
evalounew Function. - Congelado por teste de regressão: a suíte falha se qualquer handler inline ou
setAttribute("on…")reaparecer no código servido. A dívida não volta.
Criptografia e segredos
🗝️Secret Manager
Chaves de pagamento, segredo do app Meta, chaves de cifra e de provedores de IA vivem no Google Secret Manager — nunca no repositório, nunca no frontend, nunca em log.
🔐AES-256-GCM em repouso
Chaves de IA dos agentes e tokens do Google Calendar são cifrados com AES-256-GCM (cifra autenticada: adulteração é detectada, não só impedida).
🧳Cofre no navegador
Chaves de IA configuradas pelo usuário ficam em um cofre WebCrypto AES-GCM, uma chave por provedor, sem trafegar em claro.
✍️Webhooks assinados
Pagamentos (AbacatePay) e Meta validam HMAC-SHA256 do corpo cru e processam de forma idempotente — um evento repetido ou forjado não produz efeito.
Auditoria e rastreabilidade
Seis trilhas independentes. Tudo que importa deixa rastro — e o rastro não vira um novo vazamento.
| Trilha | Origem | Registra |
|---|---|---|
| Auditoria de negócio | Ações do usuário | Ciclo de vida do lead, aceites LGPD — append-only, por dono |
| Eventos de segurança | Backend | Tentativas negadas, limitadas ou suspeitas — só hashes |
| Guardas de middleware | Backend | Amostragem de rate limit e atestação de cliente |
| Contadores de janela | Backend | Base dos limites por IP/usuário |
| Atividade administrativa | Admin | Licenças, rollups de uso |
| Auditoria LGPD | API LGPD | Toda operação sobre direitos do titular — somente-servidor |
WhatsApp isolado por usuário
Conversas são o dado mais sensível do corretor. O módulo de WhatsApp foi desenhado para que nenhuma mensagem cruze a fronteira de uma conta.
🆔Identidade canônica
Cada sessão de WhatsApp é amarrada ao identificador único do usuário no provedor de identidade — não a um nome derivado do e-mail. Colisão entre contas é impossível por construção.
🧪Testado com 40 tenants
Harness multiusuário com 40 contas simultâneas e 0 violações cross-tenant. Conexão protegida por trava in-flight: nunca dois sockets para a mesma sessão.
🔒Credenciais somente-servidor
Credenciais de sessão e histórico de conversas ficam em coleções invisíveis ao navegador, acessadas apenas pelo microserviço com App Check em bloqueio.
🎭Logs mascarados
Observabilidade do serviço sem PII: números e identificadores aparecem mascarados nos logs operacionais.
IA responsável
🤝Suggest-only
Os agentes de IA sugerem; não enviam mensagens, não decidem crédito nem questões jurídicas. A palavra final é sempre do corretor.
📉Metering sem conteúdo
O controle de consumo de IA registra volumes e custos — nunca prompts nem respostas em claro.
🧯Provedores sob allowlist
O backend só conversa com endpoints de provedores aprovados; chaves cifradas em AES-256-GCM; texto de IA renderizado com escape.
O uso de IA e agentes é coberto por um Relatório de Impacto (RIPD/DPIA) dedicado, com tabela de riscos e supervisão humana obrigatória.
Resiliência e controle operacional
🎚️Kill-switches por controle
Rate limit, App Check (por superfície), sessão/dispositivo, verificação de identidade LGPD e limpeza de retenção têm interruptores independentes: off → monitor → bloqueio. Reversão em minutos, sem redeploy do produto.
⚖️Disponível sem abrir brechas
Falha de infraestrutura nunca derruba a operação do corretor. Violação de política — dispositivo extra, token inválido, identidade não verificada — é sempre bloqueada. A limpeza de dados é fail-closed: em caso de erro, nada é apagado.
💾Backup e recuperação pontual
Banco com point-in-time recovery (~7 dias) e procedimento de restore documentado e ensaiado.
🔁Rollout medido, sempre
Cada controle de bloqueio entrou em produção depois de uma fase de monitoramento com contagem de impacto — e com o caminho de rollback escrito antes de ligar.
Direitos do titular que funcionam
Central de Privacidade & LGPD dentro do CRM, com backend próprio. Cada direito tem um fluxo real, auditado, e nenhum dado pessoal é eliminado sem confirmação e revisão.
| Direito | Como o ImobPilot atende |
|---|---|
| Acesso e portabilidade art. 18, II e V | Exportação estruturada (JSON) de leads, execuções de agentes e memória de IA — somente do próprio dono, gerada pelo backend e nunca contendo segredos ou tokens. |
| Correção art. 18, III | Edição direta no CRM, com trilha de auditoria por dono. |
| Eliminação art. 18, VI | Solicitação registrada → identidade verificada → simulação de impacto (admin) → pseudonimização com trilha. Nunca instantâneo, nunca sem revisão. |
| Pseudonimização / restrição | Dados pessoais substituídos por marcador em uma allowlist fixa de campos, preservando integridade referencial e obrigações fiscais. |
| Informação e transparência | Política de privacidade, termos de uso e página de exclusão de dados públicos; Central LGPD na barra lateral do CRM. |
| Registro e revogação | Toda solicitação vira documento auditável; aceites versionados com hash do texto aceito. |
Identidade verificada em bloqueio
Ninguém apaga dados de outra pessoa. Fluxos destrutivos exigem e-mail verificado pelo provedor de identidade — lido do token assinado, nunca do corpo da requisição.
🛑Bloqueio ativo desde 27/07/2026
Confirmação de exclusão com identidade não verificada recebe 403 e gera evento de segurança (só hashes). A exportação de dados — não destrutiva — segue livre.
📊Ligado com prova de impacto
Antes do bloqueio: auditoria de prontidão e contagem em produção — 0 solicitações legítimas seriam afetadas. Rollback previsto em um único deploy.
Processamento administrativo com barreiras cumulativas
- Simulação de impacto (somente leitura) obrigatória antes de qualquer ação, gerando evidência.
- Justificativa registrada (apenas o hash é auditado) + frase de confirmação exata.
- Evidência da simulação precisa bater com a última executada; status elegível; identidade do titular verificada.
- Lock idempotente (compare-and-set): impossível executar duas vezes.
- Dados retidos por base fiscal, de segurança ou de auditoria não são tocados. Contador de exclusões físicas: sempre zero.
Consentimento e transparência
📜Memorando de primeiro acesso
No primeiro login, o uso do CRM fica bloqueado até leitura, identificação nominal e aceite. Gravado: nome, e-mail, versão, hash do texto aceito, data, origem. Nova versão do memorando exige novo aceite.
🧩Termos por módulo
Módulos sensíveis — Finance, Calculadora e Zap/WhatsApp — têm termos LGPD próprios com gate de entrada fail-closed: sem assinatura, o módulo não abre.
🗄️Fonte de verdade no servidor
O aceite vale pelo registro no banco, com documento determinístico, sem exclusão e com dono intransferível. Cache local só evita bloqueio indevido offline após um aceite confirmado.
🌐Páginas legais públicas
Política de privacidade, termos de uso e página de exclusão de dados descrevem finalidade, base legal, prazos de retenção, transferência internacional e o canal do DPO — mantidas coerentes com a operação real.
Retenção com critério
Cada coleção tem prazo e ação definidos. Dados técnicos temporários expiram; dados de negócio, fiscais e de auditoria são preservados pelo tempo que a lei exige. Nada é apagado por automação sem aprovação explícita.
Registro declarativo de retenção
Toda coleção é classificada (expirar, revogar, arquivar, reter, revisar). Coleção desconhecida cai automaticamente em revisar — nunca em expirar.
Simulação somente leitura
Relatório administrativo conta candidatos vencidos por coleção e classifica a ação futura, com e-mails mascarados e sem payload. Exclusão automática: zero.
Limpeza de temporários com dupla barreira
Apenas uma allowlist de dados técnicos (exportações vencidas, estados OAuth, sessões antigas, contadores, amostras CSP) pode ser limpa — com justificativa, frase de confirmação, evidência da simulação, lote máximo e idempotência.
Automação sob trava dupla
A rotina agendada só age com duas chaves explícitas ligadas; por padrão, apenas simula. Fail-closed: qualquer erro significa que nada foi apagado.
Matriz de retenção
| Tipo de dado | Prazo | Tratamento |
|---|---|---|
| Exportações LGPD geradas | 7 dias | expira |
| Estados temporários de OAuth | 1–7 dias | expira |
| Sessões de dispositivo | 90 dias | expira / revoga |
| Contadores de rate limit · amostras CSP | 30–90 dias | expira |
| Eventos de segurança · telemetria de IA | 12–24 meses | revisão periódica |
| Auditoria de negócio | 6 meses · 5 anos (defesa) | revisão periódica |
| Leads e licenças | 2–5 anos | pseudonimizar / reter |
| Cobrança · comissões · registros LGPD | 5 anos | retido por base legal |
| Conversas de WhatsApp · leads Meta · conexões OAuth | segue o lead / enquanto conectado | revisão manual |
Prazos públicos coerentes com a política de privacidade (§6). Contador de exclusões físicas em toda a plataforma LGPD: zero.
Onde os dados moram
🇧🇷Banco de dados em São Paulo
Firestore na região southamerica-east1 — dados dos titulares armazenados em território brasileiro, com recuperação pontual de ~7 dias. Verificado diretamente na configuração do projeto.
🌎Transferência internacional documentada
Parte do processamento ocorre em Cloud Functions nos EUA, sob as salvaguardas do Google Cloud DPA, criptografia em trânsito e em repouso e controle de acesso — com disclosure ao titular na política de privacidade (art. 33 da LGPD).
🏗️Infraestrutura de referência
Google Cloud / Firebase para identidade, dados e backend; microserviço de WhatsApp em servidor dedicado com atestação em bloqueio; frontend estático com cabeçalhos de segurança.
🔗Suboperadores registrados
Google Cloud/Firebase · Meta/WhatsApp · AbacatePay · provedores de IA · hospedagem — todos listados no Registro de Operações, com salvaguardas e referência na política de privacidade.
Programa de governança
Os artefatos que um cliente corporativo pede em due diligence — já escritos, versionados e mantidos.
| Artefato | O que cobre |
|---|---|
| Runbook de Resposta a Incidentes | Detectar → triar → conter → avaliar → notificar (ANPD/titulares) → remediar → postmortem. Registro de incidentes por ≥ 5 anos; exercício de mesa anual. |
| RIPD / DPIA | Relatório de impacto para IA, agentes e tratamentos de alto risco — tabela de 17 riscos com mitigações. |
| ROPA — Registro de Operações | 12 atividades de tratamento mapeadas (art. 37), com finalidades, bases legais, prazos e suboperadores. |
| DPA — Acordo de Tratamento | Papéis de controlador e operador, suboperadores e cláusula de base legal do lead. |
| Política de retenção | Matriz por tipo de dado, allowlist de execução e regras de não-exclusão. |
| Backup & restore | Procedimento documentado de recuperação do banco. |
🧭Papéis bem definidos
O corretor/imobiliária é controlador dos seus leads (define finalidade e base legal); o ImobPilot é operador desses dados — e controlador apenas dos dados da própria conta, cobrança e segurança.
🧑⚖️Encarregado nomeado
DPO identificado, com canal público de contato e prazo de resposta definido no runbook. O titular sabe com quem falar — e a empresa sabe o que fazer.
Linha do tempo — 2026
Segurança é um programa contínuo, não um evento. Marcos verificados em produção:
Visitas e comissões fechadas por dono; memorando de consentimento versionado; API LGPD publicada.
Rate limiting em bloqueio, controle de sessão/dispositivo, hardening anti-XSS, caps nas regras do banco, readiness de App Check.
Fluxos destrutivos passam a exigir e-mail verificado; programa de retenção em 3 fases e matriz de prazos concluídos.
Runbook de incidentes, RIPD/DPIA, ROPA e DPA redigidos e versionados.
679 handlers inline → 0. Política sem unsafe-inline e sem eval, validada byte a byte na origem.
Harness de 40 tenants com 0 violações; trava de socket; logs mascarados.
Banco, APIs, WhatsApp e login com atestação obrigatória — cada etapa com prova negativa e zero rejeições legítimas.
Perguntas de due diligence
As perguntas que jurídico, TI e gestores mais fazem — com as respostas que o ImobPilot já tem.
Outro corretor ou outra imobiliária consegue ver meus leads?
Não. O isolamento por dono é aplicado nas regras do banco de dados, com negação padrão. A identidade vem do token assinado do login, não de um campo que o cliente envia. Mesmo um erro de interface não expõe dados de terceiros — o banco recusa a leitura.
Meus dados ficam no Brasil?
Sim. O banco de dados fica em São Paulo (southamerica-east1). Parte do processamento em backend ocorre em servidores do Google nos EUA sob as salvaguardas do Google Cloud DPA, criptografia e controle de acesso — tudo descrito na política de privacidade, como exige o art. 33 da LGPD.
Se eu pedir a exclusão dos meus dados, o que acontece?
A solicitação é registrada, sua identidade é verificada (e-mail confirmado pelo provedor de login), um administrador executa uma simulação de impacto e, só então, os dados pessoais são pseudonimizados com trilha de auditoria. Registros fiscais e de auditoria exigidos por lei são preservados. Nada é apagado instantaneamente nem por engano.
Vocês guardam meu IP, e-mail ou navegador nos logs?
Só hashes. As seis trilhas de auditoria registram SHA-256 truncado desses valores — suficiente para investigar um incidente, insuficiente para identificar uma pessoa a partir do log.
A IA do ImobPilot lê e usa minhas conversas?
Os agentes são suggest-only: sugerem, não enviam nem decidem. O controle de consumo de IA registra volumes, nunca prompts ou respostas em claro. As chaves de provedores ficam cifradas em AES-256-GCM e o backend só fala com endpoints aprovados. O uso de IA é coberto por RIPD/DPIA próprio.
Quem consegue entrar na minha conta?
Apenas quem autenticar no Google com a sua identidade — o ImobPilot não tem senha própria para vazar. Cada sessão é validada no backend e o número de dispositivos é limitado pela licença (padrão = 1). Rotas administrativas exigem papel de admin conferido no servidor.
Como sei que a página que uso não foi adulterada com um script malicioso?
A política CSP bloqueante impede o navegador de executar qualquer script inline ou eval — mesmo que um conteúdo malicioso chegasse à página. Os arquivos servidos foram conferidos por SHA-256 contra a fonte, e um teste de regressão garante que nenhum handler inline volte a entrar no código.
Um bot ou um script de terceiros pode chamar o backend do ImobPilot?
Não. App Check com reCAPTCHA Enterprise está em bloqueio no banco, nas APIs, no WhatsApp e no login. Uma requisição sem atestado válido recebe 401 antes mesmo de chegar à autenticação.
O que acontece se a infraestrutura do Google tiver um problema?
Falha de infraestrutura não derruba a operação do corretor. Já uma violação de política — dispositivo extra, token inválido, identidade não verificada — é sempre bloqueada, independentemente da infraestrutura. Cada controle tem um interruptor próprio para reversão em minutos e o banco tem recuperação pontual de ~7 dias.
Vocês têm DPO, runbook de incidentes e registro de operações?
Sim. Encarregado nomeado e publicado; runbook de resposta a incidentes com fluxo de notificação à ANPD e aos titulares; RIPD/DPIA para IA e alto risco; ROPA com 12 atividades; DPA com papéis de controlador e operador. Tudo versionado e mantido.
Um CRM em que a segurança já veio pronta.
Cada controle desta página tem data de ativação e prova em produção. Se a sua imobiliária, o seu jurídico ou o seu time de TI quiser ver os detalhes, estamos à disposição.
ImobPilot CRM — Segurança & LGPD · Revisão 22/08/2026. Todos os controles descritos estavam ativos e verificados em produção na data de revisão; este documento é atualizado a cada entrega que altere um controle.
Este material descreve controles técnicos e organizacionais e não constitui parecer jurídico. Dúvidas sobre tratamento de dados pessoais: privacidade@imobpilot.com.br.