The controlling text is available in Portuguese. An English translation is not yet available.
1. Objeto escopo e interpretação
1.1. Este Anexo estabelece medidas técnicas e organizacionais proporcionais destinadas a proteger confidencialidade, integridade, disponibilidade, autenticidade, resiliência e tratamento legítimo de Dados do Cliente e Dados Pessoais no Serviço.
1.2. As medidas aplicam-se aos componentes, pessoas, fornecedores e ambientes sob controle da Aivyro na extensão do Serviço contratado, sem transferir controles de dispositivo, rede, usuário, integração ou sistema administrados pelo Cliente.
1.3. O Anexo complementa Termos B2B, DPA, Retenção, Subprocessadores, Termos de Integrações, Desenvolvedores e Gravação; requisito setorial ou adendo aprovado poderá estabelecer proteção superior ou específica.
1.4. Referência a prática, objetivo ou categoria de controle não equivale a certificação, atestado independente, garantia absoluta ou adoção integral de framework, e somente será claim público quando houver evidência atual.
1.5. Medidas evoluirão segundo risco, tecnologia, ameaça, custo e estado da técnica sem reduzir indevidamente a proteção contratada; mudança material adversa será avaliada e tratada conforme DPA e Pedido.
2. Modelo de responsabilidade compartilhada
2.1. Aivyro protegerá infraestrutura, aplicação, identidades de serviço, código, segredos, dados e operações sob seu controle; Cliente protegerá usuários, papéis, endpoints, dispositivos, contas externas, conteúdo, configurações e credenciais sob o seu.
2.2. Dependência de nuvem, edge, pagamento, comunicação, modelo ou integração não elimina a responsabilidade da Aivyro por seleção, contrato, configuração e supervisão que estejam sob seu domínio.
2.3. Cliente não será responsabilizado por controle invisível ou falha exclusiva da Aivyro, e a Aivyro não responderá por alteração exclusiva do Cliente, observados contribuição causal, dever de alerta e obrigação inderrogável.
2.4. Matriz de responsabilidade poderá ser detalhada no Pedido para ambiente dedicado, integração, setor, residência, chave gerenciada, backup ou operação especial, prevalecendo sobre descrição genérica.
2.5. Nenhuma parte utilizará responsabilidade compartilhada para omitir evento, atrasar contenção ou recusar cooperação razoável em risco que alcance ambas as camadas.
3. Governança e gestão de risco
3.1. Aivyro manterá programa de segurança compatível com porte, complexidade, natureza do Serviço e sensibilidade dos dados, com responsáveis, políticas, avaliação, prioridades, tratamento e revisão documentados.
3.2. Riscos serão identificados considerando ativos, ameaças, vulnerabilidades, probabilidade, impacto, titulares, clientes, disponibilidade e obrigações, com aceitação, mitigação, transferência ou eliminação atribuída a owner.
3.3. Mudança relevante de arquitetura, fornecedor, modelo, região, categoria de dado ou capacidade será submetida a análise proporcional antes da produção ou por procedimento emergencial controlado.
3.4. Exceção a política ou controle terá justificativa, escopo, prazo, aprovador, risco residual e medida compensatória, não podendo permanecer indefinidamente por ausência de revisão.
3.5. Evidência do programa será preservada conforme necessidade e disponibilizada ao Cliente nos limites do DPA, segurança, confidencialidade e direitos de terceiros.
4. Inventário classificação e minimização
4.1. Sistemas, serviços, repositórios, bancos, filas, buckets, integrações, modelos, ambientes e fornecedores relevantes serão inventariados com owner e criticidade suficientes para gestão.
4.2. Dados serão classificados por natureza, sensibilidade, finalidade, origem, território, retenção e impacto, distinguindo credencial, conteúdo, metadado, log, gravação, biometria, cobrança e derivado de IA.
4.3. Coleta e conservação serão limitadas ao necessário; dado sem finalidade, owner ou prazo deverá ser eliminado, anonimizado, bloqueado ou regularizado conforme lei e capacidade técnica.
4.4. Fluxos materiais de entrada, armazenamento, processamento, saída, suboperação, exportação e descarte serão mapeados para permitir direitos, incidentes, transferência e exclusão.
4.5. Ambiente de teste utilizará dado sintético, anonimizado ou minimizado quando possível, e dado real somente com necessidade, proteção e autorização equivalentes ao risco.
5. Identidade autenticação e contas
5.1. Acesso será vinculado a identidade individual ou de serviço, com autenticação adequada ao risco e proibição de conta compartilhada quando prejudicar responsabilização e auditoria.
5.2. Criação, alteração e remoção de acesso seguirão aprovação, função e ciclo de vínculo, com desativação tempestiva de conta desligada, comprometida ou sem necessidade.
5.3. Autenticação multifator será exigida nos contextos definidos pela avaliação e capacidade técnica, especialmente para privilégios, produção, provedores e repositórios críticos, sem claim universal antes de comprovação.
5.4. Recuperação de conta, convite, troca de e-mail e elevação de privilégio serão protegidos contra sequestro, enumeração e bypass, com validação independente quando o risco exigir.
5.5. Sessão terá expiração, revogação e proteção compatíveis com sua natureza; logout visual sem invalidação do artefato persistente não será considerado revogação suficiente.
6. Autorização menor privilégio e segregação
6.1. Acesso a dado e ação será autorizado no servidor segundo Organização, usuário, papel, escopo, objeto e finalidade, sem confiar exclusivamente em identificador fornecido pelo cliente.
6.2. Privilégios serão mínimos, temporários quando possível e revisados; administrador, suporte, engenharia e serviço não receberão acesso amplo por mera conveniência.
6.3. Dados de Organizações serão segregados lógica ou fisicamente conforme arquitetura, com controles e testes contra acesso cross-tenant, referência direta insegura, cache indevido e contexto residual.
6.4. Operação privilegiada, impersonação ou acesso de suporte exigirá finalidade, autorização, duração e registro compatíveis, com mascaramento ou ambiente controlado quando suficiente.
6.5. Mudança de Organização ativa deverá invalidar ou recontextualizar cache, sessão, stream, fila e consulta afetados, evitando que interface aparente nova identidade enquanto dado anterior permanece acessível.
7. Segredos chaves e credenciais
7.1. Chaves, tokens, senhas, certificados, signing secrets e material criptográfico serão armazenados em mecanismo apropriado e não incluídos em código, imagem, log, analytics, prompt ou ticket comum.
7.2. Segredo terá owner, finalidade, escopo, ambiente, rotação e revogação compatíveis, e valor exposto será invalidado em vez de apenas ocultado do histórico visível.
7.3. Acesso humano a segredo será limitado e auditável; aplicação receberá credencial de serviço e permissão mínima quando possível.
7.4. Credencial de Cliente ou provedor será utilizada somente para a integração autorizada e excluída de exportação ordinária, suporte não autenticado e treinamento de modelo.
7.5. Comprometimento suspeito acionará contenção, rotação, revogação, análise de uso e comunicação conforme impacto, preservando evidência sem conservar segredo desnecessariamente.
8. Criptografia e proteção de transmissão
8.1. Dados serão protegidos em trânsito por mecanismos atuais e apropriados quando tecnicamente aplicáveis; exceção exigirá necessidade, risco e controle compensatório documentados.
8.2. Proteção em repouso será definida conforme sensibilidade, armazenamento, provedor e arquitetura, sem prometer algoritmo, chave dedicada ou cobertura universal não comprovados.
8.3. Chaves criptográficas serão geridas com acesso, rotação, backup e separação compatíveis com o risco, evitando que dado e chave permaneçam expostos no mesmo contexto sem controle.
8.4. URL assinada, token temporário e link compartilhado serão tratados como credencial, com escopo e validade limitados quando suportados, e não serão publicados ou reutilizados fora da finalidade.
8.5. Hash, checksum ou assinatura poderá demonstrar integridade ou proveniência técnica, mas não prova consentimento, licitude, autoria humana ou completude do conteúdo.
9. Desenvolvimento seguro e mudanças
9.1. Alterações seguirão controle de versão, revisão, verificação e autorização proporcionais ao risco, com separação entre desenvolvimento e produção quando aplicável.
9.2. Entradas serão validadas e saídas tratadas contra injeção, execução, exposição, abuso de arquivo, payload excessivo e outros riscos pertinentes à tecnologia.
9.3. Autorização, tenant isolation, dados sensíveis, billing, comunicação, gravação e operação de IA receberão revisão compatível com consequência e não serão aprovados apenas por teste de happy path.
9.4. Artefato, imagem e dependência serão obtidos de fonte controlada e avaliados; componente vulnerável ou abandonado será atualizado, isolado, substituído ou aceito formalmente conforme risco.
9.5. Segredo e dado real não serão incorporados a fixture, commit, bundle ou log de build; detecção posterior exigirá remoção do caminho ativo e revogação do material persistente.
10. Vulnerabilidades patches e testes
10.1. Vulnerabilidades serão identificadas por fontes, ferramentas, testes, fornecedores e relatos adequados e triadas segundo explorabilidade, alcance, dado, privilégio e impacto.
10.2. Prazo de correção dependerá da severidade e mitigação, sem número público não validado; risco crítico poderá exigir bloqueio, rotação, isolamento ou rollback antes da solução definitiva.
10.3. Testes de segurança serão autorizados, delimitados e conduzidos para evitar dano, acesso indevido ou indisponibilidade, preservando achado, versão e confirmação de correção.
10.4. Relato responsável terá canal e regras próprios; boa-fé será considerada, mas não autoriza extorsão, persistência, acesso a terceiro, exfiltração excessiva ou divulgação prematura.
10.5. Exceção de patch exigirá justificativa, medida compensatória e reavaliação, não podendo transformar incompatibilidade operacional em aceitação permanente sem owner.
11. Logging monitoramento e detecção
11.1. Eventos relevantes de autenticação, autorização, privilégio, configuração, credencial, integração, exportação, exclusão, erro e segurança serão registrados conforme risco e capacidade.
11.2. Logs serão protegidos contra acesso, alteração e retenção excessiva, minimizando conteúdo e segredos; ausência de necessidade investigativa não autoriza replicar payload integral.
11.3. Monitoramento buscará comportamento anômalo, falha, abuso e degradação dentro do escopo operacional, sem prometer detecção de todo evento ou vigilância contínua não comprovada.
11.4. Alertas terão owner, severidade, roteamento e procedimento de resposta; alerta silencioso ou sem ação não será tratado como controle efetivo.
11.5. Horários e correlação preservarão fuso e fonte suficientes para reconstrução, com cautela para não apresentar telemetria parcial como prova conclusiva.
12. Infraestrutura rede e ambientes
12.1. Produção será logicamente separada de desenvolvimento e teste conforme arquitetura, com acesso e credenciais próprios e processo controlado de implantação.
12.2. Exposição de rede, porta, serviço e endpoint será limitada ao necessário, protegida por autenticação, firewall, gateway, edge ou controle equivalente conforme contexto.
12.3. Configuração de nuvem, container, armazenamento, banco, fila e runtime será gerida por fonte e revisão adequadas, evitando mudança manual não rastreada em produção quando houver caminho controlado.
12.4. Imagem, pacote e build deverão ser reproduzíveis ou verificáveis em grau razoável, com proveniência e controle contra alteração não autorizada conforme criticidade.
12.5. Ambiente e fornecedor serão avaliados por região, dado, contrato, continuidade e transferência, sem que presença global do provedor signifique que todo dado circule por todas as regiões.
13. Fornecedores e suboperação
13.1. Fornecedor que trate Dado do Cliente será submetido a diligência proporcional sobre serviço, segurança, privacidade, localização, subcontratação, incidente, continuidade e destinação antes ou durante o uso.
13.2. Contrato imporá confidencialidade, proteção, uso limitado, cooperação, incidente e retorno ou exclusão compatíveis com o DPA e risco, sem depender apenas de página promocional.
13.3. Aivyro manterá inventário e governança de subprocessadores e distinguirá fornecedor próprio de aplicação selecionada diretamente pelo Cliente.
13.4. Mudança material de fornecedor ou local seguirá aviso, objeção e transferência aplicáveis, podendo exigir mitigação, substituição ou término quando proteção adequada não puder ser mantida.
13.5. Evidência de fornecedor será revisada conforme risco e validade, não sendo certificação expirada ou escopo diferente apresentada como garantia do Serviço Aivyro.
14. Backups continuidade e recuperação
14.1. Cópias e recuperação serão planejadas conforme criticidade, integridade, região, retenção e dependência, distinguindo backup de alta disponibilidade, replicação e arquivo.
14.2. Acesso a backup será restrito e protegido, e seu ciclo de expiração impedirá que exclusão de produção resulte em conservação indefinida sem finalidade.
14.3. Testes de restauração e continuidade serão realizados conforme programa e compromisso aplicáveis, registrando resultado, lacuna e ação corretiva.
14.4. RTO, RPO, frequência, duração e região somente serão vinculantes quando comprovados e previstos no Pedido; existência de backup não cria valor numérico implícito.
14.5. Recuperação priorizará integridade e autorização, podendo ocorrer de forma gradual; restauração de serviço não prova que toda fila, integração ou dado foi reconciliado.
15. Gestão de incidentes
15.1. Aivyro manterá processo para receber, classificar, conter, investigar, erradicar, recuperar, comunicar e aprender com incidentes conforme natureza e risco.
15.2. Funções e contatos serão definidos, incluindo tecnologia, privacidade, jurídico, comunicação e gestão quando pertinentes, sem depender de decisão improvisada durante o evento.
15.3. Evidência será preservada com integridade e acesso limitado; contenção poderá exigir revogação, isolamento, suspensão, bloqueio ou redução temporária de capacidade.
15.4. Notificação ao Cliente seguirá DPA e lei com informação razoavelmente disponível, distinguindo suspeita, confirmação, impacto e atualização; prazo regulatório aplicável não será substituído por conveniência operacional.
15.5. Revisão posterior identificará causa, alcance, eficácia, recorrência e correção, sem que relatório preliminar ou ausência de exploração conhecida encerre o dever de acompanhamento.
16. Pessoas confidencialidade e treinamento
16.1. Pessoas com acesso relevante estarão sujeitas a confidencialidade e deveres compatíveis antes do acesso e após o desligamento na extensão necessária.
16.2. Treinamento será proporcional à função e incluirá dados, phishing, credenciais, incidentes, engenharia social e requisitos específicos quando aplicáveis.
16.3. Contratação, mudança de função e desligamento acionarão concessão, revisão e revogação de acesso, com atenção a privilégio, dispositivo e segredo.
16.4. Violação interna será investigada e tratada segundo gravidade, lei, contrato e política, preservando direitos e evidência sem tolerar acesso por curiosidade ou conveniência.
16.5. Prestador e terceiro receberão somente acesso necessário, com prazo, supervisão e obrigação equivalentes ao risco do trabalho.
17. Ciclo de dados e direitos
17.1. Retenção e exclusão seguirão classe, finalidade, contrato, lei e hold, com procedimentos para produção, derivados, filas, logs, fornecedores e backups conforme possibilidade técnica.
17.2. Exportação e direito serão autenticados e autorizados, evitando que atendimento a solicitante exponha dados de outra pessoa ou Organização.
17.3. Anonimização somente será declarada quando risco de reidentificação for reduzido segundo meios razoáveis e contexto; pseudonimização continuará sujeita à proteção correspondente.
17.4. Dados sensíveis, gravações, voiceprints, credenciais e pagamento terão controles adicionais conforme política específica, não sendo tratados como conteúdo comum por conveniência técnica.
17.5. Hold será limitado em escopo, acesso e duração, revisado e liberado quando o fundamento cessar, sem converter preservação legítima em cópia paralela indefinida.
18. Auditoria compromissos e vigência
18.1. Auditoria do Cliente seguirá DPA, priorizando questionário, relatório e evidência independente antes de teste intrusivo, com confidencialidade e não interferência.
18.2. Certificação ou relatório, se obtido, somente será descrito conforme entidade, escopo, período, ambiente e ressalvas reais, sem extensão a módulo não examinado.
18.3. Deficiência identificada será priorizada e acompanhada conforme risco; ausência de achado não será garantia de invulnerabilidade, e risco aceito não eliminará obrigação legal.
18.4. Declarações deste Anexo devem corresponder à arquitetura, à configuração, aos contratos, aos testes e aos responsáveis atuais. Obrigação futura, objetivo e controle implementado serão distinguidos e divergência material será corrigida sem ampliar silenciosamente o compromisso.
18.5. Este Anexo vigora na data indicada e torna-se contratualmente vinculante quando incorporado ao Pedido ou ao DPA. Ele descreve medidas no alcance factual indicado, não constitui certificação, garantia de invulnerabilidade ou promessa universal sobre ambiente, módulo ou fornecedor não abrangido.