FAQ

Segurança e LGPD

Dados ficam isolados por tenant. Senhas e credenciais sensíveis são criptografadas at-rest. Decisões de retenção e anonimização envolvem o time Interaflow conforme requisitos do tenant.

Atualizado em 04 de maio de 2026

Posicionamento

Esta página resume as práticas de segurança e tratamento de dados do Interaflow do ponto de vista do tenant. Não substitui o contrato comercial nem o anexo de proteção de dados (DPA) que acompanha a contratação — é referência operacional para quem precisa entender como o produto trata dados antes de planejar operação ou auditoria.

Sempre que houver decisão regulatória crítica (retenção específica por compliance setorial, anonimização sob demanda, emenda de DPA), envolva o time Interaflow no processo.

Onde os dados ficam

Banco principal (Postgres) — armazena Conversas, Campanhas, Atendentes, Filas, configurações do tenant. Isolamento por tenant_id em todas as tabelas relevantes; queries filtram por esse identificador na camada de aplicação.
Storage de objeto (MinIO ou S3 compatível) — gravações de chamada, documentos de Conhecimento, Materiais, uploads em geral. Buckets isolados por escopo conforme a arquitetura do tenant.
OpenAI — tokens enviados para inferência (chat, transcrição, embeddings) chegam à OpenAI conforme a chave do tenant. Cabe ao tenant a relação contratual com a OpenAI, incluindo configurações como Zero Data Retention se aplicável.
Provedores de canal — mensagens trafegam pelos provedores contratados (Meta Cloud API, Gupshup, Zenvia, etc.). Cada provedor tem seu próprio termo de tratamento.

Isolamento por tenant

Toda tabela de aplicação carrega tenant_id como filtro obrigatório no acesso.
Usuários autenticam contra um único tenant (User.tenant_id), exceto superuser, que atravessa tenants para operação Interaflow.
E-mails de User são únicos globalmente — uma pessoa não pode ter conta em dois tenants com o mesmo e-mail.
Logs operacionais agregam métricas por tenant para evitar cruzamento entre clientes.

Criptografia at-rest

Dados sensíveis são criptografados antes de armazenar:

Dado	Como é protegido
Senhas de User	Hash com algoritmo de senha forte (não reversível).
Senhas SIP (credenciais de Voz)	Criptografia simétrica com chave de aplicação. Nunca renderizadas no DOM ou em logs; cliente WebRTC obtém via endpoint autenticado audit-logado.
Credenciais de provedor (Canal — token Meta, API key Zenvia, etc.)	Criptografia simétrica antes de gravar. Nunca expostas em logs ou GET de leitura.
Senha SIP de tronco	Mesmo padrão.
API keys de integradores	Hash SHA-256 (irrecuperável); apenas prefixo aparece na UI.
Chave OpenAI do tenant	Criptografia simétrica.
Conteúdo de mensagens / Conversas	Texto plano no banco do tenant, isolado por `tenant_id`.
Gravações	Arquivo binário no storage isolado por bucket/path do tenant.

A chave de aplicação usada para criptografia simétrica reside no ambiente de execução (variável de ambiente, segredo de infraestrutura) — fora do banco de dados.

Em trânsito

HTTPS / TLS para tráfego HTTP.
WSS (WebSocket seguro) para softphone WebRTC e streams de telemetria.
DTLS-SRTP para mídia WebRTC entre o navegador do Atendente e o Asterisk — chamada de voz é criptografada ponta a ponta na perna do navegador.
SIP em UDP/TCP entre Asterisk e operadoras pode ser TLS ou não, dependendo da operadora — configurável por Tronco SIP.

Gravações de chamada

Captura é controlada por Campanha via recording_mode (desligado, pré-conexão ou pós-conexão). Sem ativar, não há gravação.
Arquivos .wav ficam no storage de objeto.
Metadados ficam no banco principal para busca rápida em Gravações.
O Atendente normalmente avisa “ligação está sendo gravada” no início — política da operação, não automática (configure no greeting da Campanha ou no Fluxo).

Retenção

A política de retenção do bucket é configurada no nível de infraestrutura — não há painel self-service para o admin do tenant alterar. Se sua operação tem requisitos específicos (retenção mínima por compliance, exclusão automática após N dias), alinhe com o time Interaflow no onboarding ou via ticket formal.

Anonimização sob demanda

A redação automática de trechos sensíveis em gravações (números de cartão, dados de saúde) ainda não está exposta como funcionalidade self-service. Casos pontuais — auditoria externa, processo judicial, pedido formal — podem ser tratados pelo time Interaflow com edição direta do arquivo, sob solicitação documentada.

Conversas e PII

Mensagens ficam em texto plano no banco; isolamento por tenant_id.
Guardrails podem detectar PII (CPF, CNPJ, telefone, e-mail) no input do contato e mascarar com placeholders antes de enviar à IA — defesa prática contra envio acidental de dado sensível ao modelo.
A regra pii_leak no output ajuda a impedir que a IA repita dado interno na resposta ao contato.

Combinação recomendada para operações sensíveis: pii_detection (input) + pii_leak (output) ativos no Fluxo.

Direitos do titular (LGPD)

A LGPD prevê direitos do titular dos dados (acesso, correção, exclusão, portabilidade). No Interaflow:

Acesso e correção — Conversa do contato fica acessível por busca em Conversas e Relatórios. Correção de dados de contato é feita no cadastro do contato.
Exclusão — soft delete na maioria das tabelas (deleted_at populado). Exclusão definitiva (hard delete) por solicitação formal envolve o time Interaflow para preservar consistência histórica.
Portabilidade — exportação via Relatórios ou via API. Para volume grande, alinhe formato e janela com o time Interaflow.

Acesso à plataforma

RBAC por papel (Usuários e papéis) — granularidade por role, sem permissões nominais por recurso.
SSO Google (SSO) recomendado para empresas com Workspace; Forçar SSO bloqueia login por senha exceto superuser.
Sem MFA nativo — segurança adicional vem do SSO Google (que herda política de MFA do Workspace).
Soft delete preserva histórico ao desativar User; é o caminho preferido para offboarding.

Auditoria operacional

last_used_at / last_used_ip em chaves de API.
Audit log quando o cliente WebRTC busca segredo de Voz.
Audit log em disparos de Guardrail (com hash da mensagem para preservar conformidade).
created_by_user_id em registros relevantes (Mensagens pré-prontas, Formulários de Qualidade, etc.) para rastreabilidade de quem fez o quê.

Certificações

A lista de certificações do produto (ISO 27001, SOC 2, etc.) pode evoluir ao longo do tempo. Não citamos aqui o que ainda não foi formalizado — para a lista atualizada de certificações ativas e atestados disponíveis, solicite ao time Interaflow.

Boas práticas do tenant

Combine SSO com política MFA do Workspace — proteção prática mais forte que senha local.
Rotacione chaves de API trimestralmente (guia).
Habilite Guardrails de PII em Fluxos que tratam dado sensível.
Documente a base legal (consentimento, execução de contrato, legítimo interesse) para tratamento dos dados que entram no Interaflow — incluindo gravações.
Limite o uso de gravações em Campanhas de baixa necessidade — nem toda operação precisa gravar tudo.
Comunique a gravação ao contato quando aplicável (lei e boa prática).
Audite usuários ativos mensalmente — desative quem saiu da empresa.
Inclua ofuscação na origem ao subir dados em Mailing (mascarar CPF, encoding correto, base legal).

Pontos em aberto

Retenção self-service de gravações não exposta na UI.
Anonimização self-service de gravações idem.
MFA nativo ainda não disponível — fica por conta do SSO.
Webhooks de saída self-service ainda em construção (ver Webhooks).

Para qualquer um desses, alinhe necessidade com o time Interaflow.