Política de Segurança, Privacidade e SLA

1. SLA — Atendimento, Disponibilidade e Prazo de Resolução

1.1 Disponibilidade (uptime)

Exclusões do cálculo de disponibilidade:

• Janelas de manutenção programadas e devidamente comunicadas;
• Indisponibilidade decorrente de força maior (Art. 393 do CC), eventos climáticos extremos, falhas em provedores de infraestrutura listados na seção 5 quando fora do controle razoável da Axiom;
• Uso indevido pelo cliente, ataques originados a partir de credenciais do cliente, ou alterações de integração realizadas pelo cliente sem coordenação prévia.

Créditos de SLA (aplicáveis sobre a mensalidade do mês de descumprimento):

O crédito é o remédio exclusivo por descumprimento de SLA de disponibilidade.

1.2 Atendimento e prazos de resolução

Canais oficiais: Suporte por e-mail (canal oficial de SLA): support@tryaxiom.ai — Reportes de segurança e vulnerabilidades: security@tryaxiom.ai — Canal direto (Slack/WhatsApp dedicado): mediante contratação de plano Enterprise.

Os e-mails acima são monitorados em dias úteis dentro do horário de atendimento; incidentes P1 (Crítico) recebem plantão 24×7 conforme tabela de severidade.

Horário de atendimento padrão: segunda a sexta, 09:00–18:00 BRT, exceto feriados nacionais. Incidentes classificados como P1 (Crítico) são atendidos em regime 24×7 mediante plantão de prontidão.

Classificação de severidade:

Os prazos contam a partir da abertura formal do ticket no canal oficial. A classificação inicial é proposta pela Axiom e pode ser repactuada por solicitação justificada do cliente.

2. Política Formal de Segurança da Informação e Gestão de Incidentes

A Axiom mantém uma Política de Segurança da Informação (PSI) formal, revisada no mínimo anualmente, aprovada pela liderança e comunicada a todos os colaboradores. Os pilares abaixo resumem os controles em vigor.

2.1 Governança

• Encarregado pelo Tratamento de Dados Pessoais (Encarregado/DPO) designado nos termos do Art. 41 da LGPD, com identidade e canal de contato publicados no site institucional. Atualmente: Guthyerrz Silva (Encarregado titular) e Victor Fernandes (Encarregado substituto), pelo canal privacy@tryaxiom.ai.
• Esta PSI é aprovada por Guthyerrz Silva e Victor Fernandes em nome da liderança da Axiom.
• Revisão anual da PSI e dos procedimentos derivados.
• Treinamento obrigatório de segurança e privacidade para todos os colaboradores e prestadores no onboarding e refresher anual.

2.2 Controle de acesso

• Autenticação multifator (MFA) obrigatória em todos os sistemas administrativos, provedores de infraestrutura e ferramentas internas.
• Princípio do menor privilégio: acesso a dados de produção restrito ao pessoal estritamente necessário, revogado em ≤ 24 horas após desligamento ou mudança de função.
• Segregação de ambientes: desenvolvimento, homologação e produção são ambientes isolados, com credenciais e bancos de dados distintos. Dados reais de produção nunca são copiados para ambientes inferiores.
• Logs de acesso administrativo retidos por mínimo de 12 meses.

2.3 Criptografia

• Em trânsito: TLS 1.2+ obrigatório em todos os endpoints públicos (HSTS habilitado).
• Em repouso: criptografia AES-256 nativa do provedor de banco de dados (Neon) e do armazenamento de objetos (Amazon S3, criptografia SSE-S3 ou SSE-KMS).
• Senhas armazenadas com hash moderno (Argon2id ou bcrypt com fator ≥ 12).
• Segredos de aplicação geridos via secret manager do Fly.io; nunca versionados em código-fonte.

2.4 Desenvolvimento seguro (SDLC)

• Todo código passa por revisão de pares (peer review) antes de chegar à produção.
• Verificação automatizada de vulnerabilidades em dependências de terceiros a cada build, com bloqueio do pipeline em caso de vulnerabilidades de severidade alta ou crítica.
• Política restritiva de dependências de terceiros formalmente documentada, com revisão obrigatória antes da inclusão de qualquer nova biblioteca — reduzindo a superfície de ataque de cadeia de suprimentos (supply chain).
• Monitoramento contínuo de erros e desvios via Sentry / PostHog Error Tracking.

2.5 Testes e auditorias

• Vulnerability scanning contínuo nas imagens de aplicação.
• Os relatórios sumários (sem PoCs nem informações sensíveis) são disponibilizados mediante NDA a clientes corporativos sob demanda.

2.6 Gestão de incidentes de segurança

Incidente é qualquer evento que comprometa a confidencialidade, integridade ou disponibilidade de dados do cliente. O processo formal segue detecção → contenção → erradicação → recuperação → comunicação → lições aprendidas.

Compromissos de comunicação ao cliente em caso de incidente confirmado que envolva dados pessoais sob responsabilidade do cliente:

• Notificação inicial em até 24 horas após a confirmação do incidente, por e-mail ao contato de privacidade indicado pelo cliente, partindo de security@tryaxiom.ai (incidentes de segurança) ou privacy@tryaxiom.ai (incidentes envolvendo dados pessoais);
• Conteúdo da notificação conforme Art. 48, §1º da LGPD: descrição da natureza, categorias e número aproximado de titulares afetados, riscos potenciais, medidas adotadas, contato do Encarregado;
• Atualizações periódicas até a contenção e o encerramento do incidente;
• Relatório de causa-raiz (RCA) por escrito em até 10 dias úteis após o encerramento;
• Suporte ao cliente nas eventuais comunicações à ANPD e/ou aos titulares, quando aplicável.

2.7 Segurança de endpoints (dispositivos)

• Criptografia de disco obrigatória: todos os notebooks e workstations utilizados no acesso a sistemas e dados da Axiom têm criptografia de disco integral habilitada — FileVault (macOS) ou BitLocker (Windows), padrão AES-XTS-256. As chaves de recuperação são mantidas sob custódia segura (cofre de senhas corporativo), não armazenadas em texto claro.
• Acesso protegido: o acesso aos dispositivos exige autenticação, e o acesso aos sistemas de produção permanece condicionado a MFA e ao princípio do menor privilégio (Seção 2.2).
• Minimização em endpoint: dados de produção residem em nuvem (Seção 3) e não são copiados de forma persistente para os dispositivos, reduzindo a exposição em caso de perda ou furto.
• Bloqueio automático: os dispositivos são configurados para bloqueio automático de tela após inatividade.

3. Localização dos Dados (Brasil ou Exterior)

Política de residência: os dados primários do cliente — base de dados relacional, documentos e anexos, e toda a camada de aplicação que os processa — ficam armazenados em região de São Paulo, Brasil.

Serviços auxiliares de observabilidade (analytics, monitoramento de erros), orquestração de jobs assíncronos e entrega de e-mails transacionais operam em provedores que não oferecem região brasileira e portanto operam em região dos Estados Unidos. Essas transferências internacionais estão declaradas abaixo e amparadas em base legal (ver 3.1).

3.1 Transferência internacional de dados

Conforme tabela acima, quatro suboperadores operam fora do Brasil — PostHog, Trigger.dev, Sentry e Resend, todos em região dos Estados Unidos. Essas comunicações configuram transferência internacional nos termos do Art. 33 da LGPD.

A arquitetura foi desenhada para minimizar a exposição de dados pessoais nesses componentes auxiliares:

• PostHog: envio de eventos pseudonimizados (identificadores opacos em vez de PII direta sempre que possível); PII sensível (CPF, dados financeiros, conteúdo de documentos) não é enviada;
• Trigger.dev: payloads dos jobs trafegam preferencialmente como referências (IDs) aos dados, com o conteúdo sensível permanecendo no banco brasileiro;
• Sentry: stack traces e contexto técnico de erros; filtros de PII configurados para remover campos sensíveis antes do envio;
• Resend: restrito a metadados de e-mail (destinatário, remetente, assunto) e ao corpo da própria mensagem.

Base legal das transferências (Art. 33 da LGPD):

• Art. 33, II: garantias de cumprimento dos princípios e direitos do titular por meio de cláusulas contratuais específicas (Standard Contractual Clauses / Data Processing Addendum publicado pelo provedor); e
• Quando aplicável ao caso de uso, Art. 33, V, com consentimento específico do titular para a transferência.

Os DPAs de cada suboperador estão disponíveis mediante solicitação ao contato de privacidade.

4. Backup e Retenção de Dados

4.1 Estratégia de backup

4.2 Testes de restauração

A capacidade de restauração é validada em exercícios trimestrais de disaster recovery, com restauração efetiva de uma cópia do banco de produção em ambiente isolado e verificação de integridade.

4.3 Retenção de dados

4.4 Encerramento contratual

Após o término do contrato:

• Período de carência de 30 dias para o cliente exportar seus dados em formato estruturado (CSV/JSON);
• Exclusão definitiva dos dados ativos em até 30 dias após o fim da carência (total: até 60 dias após o término);
• Expurgo dos backups em até 90 dias após término, conforme as janelas de PITR vão se exaurindo naturalmente;
• Confirmação formal de exclusão emitida ao cliente.

Exceções: dados que a Axiom esteja obrigada por lei a reter (ex.: registros fiscais e contábeis nos prazos do Decreto-Lei 486/1969 e da legislação tributária) permanecem retidos pelo prazo legal mínimo, em base segregada e com acesso restrito.

4.5 Direitos dos titulares (LGPD, Art. 18)

Solicitações de acesso, correção, anonimização, portabilidade ou exclusão de dados pessoais podem ser feitas pelo titular ou, indiretamente, pelo cliente-controlador. SLA de atendimento: até 15 dias contados do recebimento da solicitação.

5. Suboperadores e Terceiros

A Axiom utiliza os seguintes suboperadores (operadores subcontratados) para a prestação do serviço. A lista completa e atualizada é mantida em sub-processors.tryaxiom.ai (a ser publicada) e mudanças são comunicadas com antecedência mínima de 30 dias, dando ao cliente o direito de oposição fundamentada.

Compromisso contratual: todo suboperador acima possui DPA assinado (ou termos públicos vinculantes equivalentes) com cláusulas mínimas de proteção no mesmo padrão deste documento, incluindo: limitação de finalidade ao serviço contratado; obrigação de confidencialidade; medidas técnicas e organizacionais equivalentes; notificação tempestiva de incidentes; direito de auditoria/relatórios SOC 2 ou equivalente.

6. Plano de Continuidade — Indisponibilidade e Falha Operacional

6.1 Detecção e monitoramento

• Verificação ativa de disponibilidade (uptime checks) a partir de pontos externos, com alarme em < 1 minuto após falha.
• Monitoramento de erros em tempo real via Sentry / PostHog Error Tracking.
• Métricas de latência e taxa de erro com dashboards internos e alertas em limiares predefinidos.
• Monitoramento dos provedores de infraestrutura (Fly.io, Neon, AWS) via status pages oficiais, com integração no canal de plantão.

6.2 Resposta a incidentes operacionais

6.3 Objetivos de recuperação

6.4 Plano de Continuidade de Negócios (BCP / DR)

• Falha de zona/região do Fly.io (GRU): redeploy automático em região alternativa do Fly.io (GIG — Rio de Janeiro, ou região mais próxima disponível) preservando residência brasileira sempre que possível;
• Falha do Neon em sa-east-1: restauração via PITR/snapshot na mesma região; em caso de indisponibilidade prolongada da região, restauração em região alternativa com disclosure imediato ao cliente sobre transferência emergencial de dados;
• Falha no S3 sa-east-1: uso da redundância nativa multi-AZ da AWS; em caso de falha regional, plano de restauração a partir de versionamento;
• Falha em PostHog, Sentry, Trigger.dev ou Resend: degradação aceitável — não afeta a operação síncrona do serviço para o usuário final, apenas a observabilidade interna, a execução de tarefas em segundo plano (que são retomadas automaticamente após o restabelecimento, sem perda — Trigger.dev garante at-least-once delivery) e a entrega de e-mails transacionais (que são reenfileirados para reenvio).

6.5 Status page pública

A Axiom mantém (ou se compromete a publicar antes do início da operação comercial) um status page público com: estado atual de cada componente do serviço; histórico de incidentes dos últimos 90 dias; próximas manutenções programadas; inscrição opcional para notificações por e-mail.

6.6 Crédito por indisponibilidade

Os créditos de SLA descritos na seção 1.1 aplicam-se automaticamente mediante solicitação do cliente em até 30 dias após o mês de descumprimento.

7. Canais Oficiais de Comunicação

Os canais abaixo são os endereços oficiais para os fins descritos. Qualquer comunicação fora desses canais não constitui notificação formal para efeitos deste documento, do contrato comercial ou do DPA.

Notificações relevantes (mudança de suboperadores, alterações desta política, relatórios de incidente) são enviadas a partir do domínio @tryaxiom.ai ao contato indicado pelo cliente na assinatura do contrato.

8. Anexos e Documentos Relacionados

• Termo de Uso da Plataforma
• Política de Privacidade (foco no titular dos dados)
• Data Processing Agreement (DPA) — Axiom × Cliente — instrumento específico assinado em conjunto com o contrato comercial, regulando os papéis de controlador (cliente) e operador (Axiom) nos termos da LGPD
• Lista de Suboperadores atualizada em sub-processors.tryaxiom.ai
• Sumário do último Pentest — sob NDA

9. Histórico de Revisões