⏱️ Leitura: 20 minutos · 🎯 Público: CISO, DPO, times de segurança, auditores, compliance, arquitetos, clientes corporativos avaliando adoção.
A Cortex foi projetada com uma premissa inegociável: nenhuma IA é realmente corporativa se não for segura e privada por design. Esta página detalha os controles técnicos, operacionais e contratuais que garantem que os dados, conversas e conhecimento da sua organização fiquem onde devem ficar — sob o seu controle.
A segurança e privacidade na Cortex são guiadas por 8 princípios:
Privacidade não é recurso opcional — é parte da arquitetura. Cada funcionalidade é desenhada considerando proteção de dados desde o início.
Cada usuário, agente, ferramenta e integração recebe apenas o acesso estritamente necessário. Nada mais.
Múltiplas camadas de controle, de modo que a falha de uma não comprometa o todo. Rede, aplicação, dados, identidade, auditoria — todas independentes.
Tudo que acontece pode ser auditado. Logs completos, rastreabilidade ponta a ponta, exportação para SIEM.
A Cortex trata o mínimo necessário para cada propósito. Filtros automáticos mascaram ou bloqueiam dados desnecessários.
Dados de organizações diferentes são isolados. Cache, memória, conhecimento, logs — tudo segregado por organização.
Seus dados, seu controle: retenção, exclusão, exportação, compartilhamento são decisões suas, não nossas.
Contratualmente explícito: o conteúdo de suas conversas, bases de conhecimento e configurações não é usado para treinar modelos de terceiros.
A Cortex implementa 7 camadas de segurança. Um atacante precisa superar todas:
┌────────────────────────────────────────────────────────────────┐
│ CAMADA 1 — PERÍMETRO │
│ WAF, DDoS protection, TLS 1.3, geofencing │
├────────────────────────────────────────────────────────────────┤
│ CAMADA 2 — IDENTIDADE │
│ SSO (SAML/OIDC), MFA, JWT com expiração, rotação de keys │
├────────────────────────────────────────────────────────────────┤
│ CAMADA 3 — AUTORIZAÇÃO │
│ RBAC granular, políticas por grupo, escopos por API key │
├────────────────────────────────────────────────────────────────┤
│ CAMADA 4 — APLICAÇÃO │
│ Filtros PII/DLP, classificação, anti-prompt injection │
├────────────────────────────────────────────────────────────────┤
│ CAMADA 5 — DADOS │
│ Criptografia em trânsito e repouso, segregação por tenant │
├────────────────────────────────────────────────────────────────┤
│ CAMADA 6 — INFRAESTRUTURA │
│ Containers isolados, hardening CIS, patching, zero-trust │
├────────────────────────────────────────────────────────────────┤
│ CAMADA 7 — AUDITORIA E OBSERVABILIDADE │
│ Logs completos, SIEM, alertas, retenção conforme política │
└────────────────────────────────────────────────────────────────┘
Cada camada é auditável individualmente.
A Cortex aplica pipelines configuráveis que inspecionam cada mensagem antes de chegar ao modelo e cada resposta antes de voltar ao usuário.
| Filtro | O que detecta | Ação |
|---|---|---|
| Filtro LGPD | CPF, CNPJ, RG, e-mail, telefone, cartão, CEP, PIS, CNH, número de passaporte, endereço IP | Mascarar, bloquear ou alertar (configurável) |
| Dados Confidenciais | Marcadores de classificação ("CONFIDENCIAL", "RESTRITO"), números de conta interna, IDs corporativos sensíveis | Conforme política |
| Classificação da Informação | Classifica automaticamente em pública/interna/confidencial/restrita | Aplica regras por classe |
| DLP (Data Loss Prevention) | Padrões configurados pela organização (códigos fonte, fórmulas, dados de clientes) | Bloqueio ou alerta |
| Auto Memory | Fatos relevantes do usuário | Persiste em memória (com política de retenção) |
| Aprimorar Prompt | Prompts mal-formados | Reescreve (opcional) |
| Markdown Normalizer | Formatação inconsistente | Normaliza |
| Filtro | Função |
|---|---|
| Remoção de PII remanescente | Garante que nenhum dado pessoal vaze na resposta |
| Marcação de classificação | Adiciona rótulo de confidencialidade quando apropriado |
| Marca d'água invisível | Rastreabilidade em caso de vazamento |
| Disclaimer contextual | Adiciona avisos em casos sensíveis (ex.: "Esta análise é apoio, não vinculante") |
| Sanitização HTML/Markdown | Previne injeções em interfaces web |
Filtros podem ser habilitados/desabilitados por:
Um colaborador colou no chat:
Prezados, o cliente João da Silva (CPF 123.456.789-00,
[email protected]) reclamou sobre o pedido #45788.
Peço análise.
O que acontece internamente:
1. Entrada bruta chega ao filtro LGPD
2. Filtro detecta: CPF, e-mail
3. Mascara para: "João da Silva (CPF ***.***.***-**,
***@exemplo.com)"
4. Registra evento no log (usuário X, hora Y, tipo: PII mascarada)
5. Modelo recebe a versão mascarada
6. Responde baseado no contexto útil (reclamação + pedido)
7. Log de auditoria: completo para investigação se necessário
O modelo não vê o CPF. O usuário tem uma resposta útil. A organização fica conforme.
Permissões em 5 dimensões:
┌──────────────────────────────────────────────┐
│ 1. IDENTIDADE │
│ Usuário + Grupo(s) herdado(s) do IdP │
├──────────────────────────────────────────────┤
│ 2. RECURSO │
│ Agente X, coleção Y, modelo Z, ferramenta W│
├──────────────────────────────────────────────┤
│ 3. AÇÃO │
│ Ler, escrever, executar, compartilhar │
├──────────────────────────────────────────────┤
│ 4. ESCOPO │
│ Próprios, da equipe, da organização │
├──────────────────────────────────────────────┤
│ 5. CONDIÇÃO │
│ Horário, localização, MFA recente, etc. │
└──────────────────────────────────────────────┘
gpt-5 só pode ser usado por grupos com budget ≥ R$ 500/mêsknowledge.read não podem escrever em coleçõesDados de organizações diferentes são logicamente isolados em todos os níveis:
Em planos enterprise, a segregação pode ser física (clusters dedicados ou on-premises).
📜 Contratualmente explícito: o conteúdo das suas conversas, bases de conhecimento e configurações NÃO é usado para treinar modelos de IA de terceiros.
Isso é garantido por:
Cada interação gera um registro estruturado com:
| Campo | Descrição |
|---|---|
request_id |
Correlação ponta a ponta |
timestamp |
Em UTC, com ms |
user_id, groups, ip, user_agent |
Identificação do requisitor |
agent_id / model_id |
O que foi usado |
prompt_hash ou prompt_masked |
Conforme política de retenção de conteúdo |
tools_called |
Ferramentas invocadas com parâmetros |
knowledge_consulted |
Bases/arquivos consultados |
filters_applied |
Filtros acionados e resultado |
tokens_in / tokens_out |
Consumo |
cost |
Em BRL |
response_hash ou response_masked |
Conforme política |
latency_ms (total e por etapa) |
Performance |
status |
Success / error / blocked |
Logs podem ser exportados em tempo real para:
Política configurável pela organização:
| Tipo | Retenção padrão recomendada |
|---|---|
| Logs de auditoria | 12-36 meses |
| Conversas completas | 30-180 dias |
| Conteúdo mascarado | 12+ meses |
| Métricas agregadas | Indefinido |
| Backups | Conforme política |
Organizações reguladas (financeiro, saúde) frequentemente configuram retenções maiores.
Logs de auditoria podem ser configurados como write-once (imutáveis), armazenados em:
Além das ameaças tradicionais (web, rede, dados), IA traz vetores próprios. A Cortex trata cada um:
Ataque: usuário (ou conteúdo externo) tenta fazer o modelo ignorar regras do prompt do sistema.
Mitigações Cortex:
👉 Ver exemplos em Engenharia de Prompts — Segurança, LGPD e anti-injeção
Ataque: documento malicioso com instruções escondidas é enviado ao modelo, que passa a seguir as instruções do documento.
Mitigações:
Ataque: tentativa de fazer o modelo responder algo que violaria sua política (gerar conteúdo ilegal, revelar segredos, etc.).
Mitigações:
Ataque: fazer o modelo revelar na resposta dados que deveriam ficar privados (PII, secrets, outros usuários).
Mitigações:
Ataque: inferir se dados específicos estavam no treinamento.
Mitigações:
Ataque: replicar o modelo via API pública (consultas massivas).
Mitigações:
Ataque: inputs especialmente construídos para confundir o modelo.
Mitigações:
Ataque: provedor de modelo compromete o pipeline.
Mitigações:
A Cortex é aderente a múltiplos frameworks:
| Requisito | Como a Cortex atende |
|---|---|
| Finalidade | Cada agente/base documenta propósito no inventário |
| Minimização | Filtros automáticos mascarem PII não-essencial |
| Base legal | Registrada no ROPA da organização |
| Transparência a titulares | Políticas customizáveis por instância |
| Direitos dos titulares | Processos para acesso, correção, exclusão, portabilidade |
| Segurança | Todos os controles descritos nesta página |
| Comunicação de incidentes | Procedimento pronto; alertas automáticos |
| Data Protection Officer | Painel dedicado; trilhas de auditoria completas |
Princípios do GDPR são observados simultaneamente. Transferências internacionais seguem SCCs (Standard Contractual Clauses) quando aplicável.
Aderência aos controles do Anexo A:
| Controle | Implementação |
|---|---|
| A.5 — Políticas | Política de segurança, uso aceitável, retenção |
| A.6 — Organização | Papéis definidos, segregação de funções |
| A.8 — Recursos | Inventário de ativos (incluindo IA) |
| A.9 — Acesso | RBAC, SSO, MFA, privilégio mínimo |
| A.10 — Criptografia | TLS 1.3, AES-256, KMS |
| A.12 — Operações | Logs, monitoramento, gestão de mudanças |
| A.13 — Comunicação | Segmentação de rede, TLS |
| A.14 — Aquisição/desenvolvimento | SSDLC, revisão de código, testes |
| A.16 — Incidentes | Processo formal, comunicação, aprendizado |
| A.17 — Continuidade | DR, RTO/RPO definidos |
| A.18 — Conformidade | Auditorias, revisões legais |
Primeiro padrão internacional certificável para IA. A Cortex dá suporte aos controles relevantes. Veja Governança de IA.
Aplicação de classificação de risco por caso de uso. Suporte a requisitos de alto risco (documentação, supervisão humana, monitoramento).
A Cortex suporta processo maduro de gestão de incidentes, incluindo os específicos de IA.
| Tipo | Exemplo | Severidade típica |
|---|---|---|
| Vazamento de dados pessoais | PII exposta em resposta ou log | Crítica (requer notificação LGPD) |
| Prompt injection bem-sucedida | Modelo violou política após ataque | Alta |
| Alucinação com dano | Resposta inventada causou prejuízo | Alta |
| Uso não-autorizado | Usuário sem permissão acessou algo | Média-Alta |
| Falha de disponibilidade | Plataforma indisponível | Média-Alta |
| Uso excessivo (FinOps) | Custo estourado por abuso ou falha | Média |
| Output inapropriado | Resposta discriminatória, ofensiva | Média-Alta |
| Violação de política de uso | Colaborador usando indevidamente | Baixa-Média |
1. DETECÇÃO
- Alertas automáticos
- Denúncia de usuário
- Alerta de SIEM
- Feedback 👎
2. TRIAGEM (primeira hora)
- Classificar severidade
- Estancar dano (suspender agente, revogar acesso)
- Comunicar comitê
3. ANÁLISE (horas a dias)
- Reconstruir linha do tempo (via logs)
- Identificar causa raiz
- Avaliar impacto
4. TRATAMENTO
- Ação técnica (correção)
- Ação com titulares (notificação LGPD se aplicável)
- Ação regulatória (se exigido)
- Ação com fornecedor (se for causa externa)
5. APRENDIZADO
- Post-mortem
- Atualização de controles
- Treinamento adicional
- Compartilhamento com comunidade interna
Para incidentes que afetem dados pessoais:
Shadow AI = colaboradores usando IA não-autorizada (ChatGPT, Gemini, Copilot pessoal) com dados corporativos. É o risco mais comum e mais subestimado.
A Cortex atende diferentes perfis de exigência de soberania:
| Modalidade | Localização típica |
|---|---|
| SaaS | São Paulo (Brasil) |
| Dedicated Cloud | Escolhido pelo cliente |
| Private Cloud | Datacenter do cliente |
| On-Premises | Datacenter do cliente |
Quando inevitáveis (ex.: chamada a API de modelo localizada no exterior):
Se você está avaliando a Cortex para adoção, este checklist cobre as perguntas típicas de um time de segurança. A SinapseTech fornece evidências e respostas formais mediante NDA:
💬 Avaliando a Cortex para a sua organização? A SinapseTech disponibiliza, sob NDA, o Security Whitepaper completo, SOC 2 / ISO 27001 attestations (quando disponíveis), DPIA templates, arquitetura detalhada e modelo de responsabilidade compartilhada. Fale com o time de Segurança e Privacidade via Atendimento e Suporte.