afka usa cookies de análise para ver como os visitantes usam o site, e um serviço que pode identificar a empresa em que um visitante trabalha. Não vendemos seus dados. Recuse e nenhum deles carrega.
afka executa agentes que se conectam às suas ferramentas e agem em seu nome, portanto segurança e controle são integrados ao produto. Esta página resume como protegemos seus dados e como você mantém o controle do que seus agentes podem fazer.
afka oferece a uma empresa colegas de IA que recebem trabalho num canal de chat, o planeiam, agem nas suas ferramentas conectadas e reportam de volta. A resposta à confiança que isso exige é uma arquitetura em que a coisa perigosa é difícil de fazer por construção. Três propriedades carregam a maior parte desse peso.
O modelo nunca vê uma credencial. Quando um agente age numa ferramenta conectada, nunca detém nem vê o token que autoriza a ação. Chama a ferramenta pelo nome, e um gateway de backend injeta a credencial no momento da execução, no servidor, fora do contexto do modelo. Uma credencial que o modelo nunca viu não pode ser vazada ou redirecionada por ele: a proteção é estrutural, não comportamental.
Dinheiro e dano irreversível sempre pedem a uma pessoa nomeada. Cada agente tem uma definição de autonomia que o cliente escolhe, e acima dela ficam dois pisos independentes que não pode baixar. Dinheiro a sair da conta do cliente, e decisões que causam dano irreversível a uma pessoa, sempre param e pedem primeiro a uma pessoa nomeada, seja qual for a definição.
Tudo é escrito onde não pode ser editado ou apagado. Cada ação, por um agente ou uma pessoa, é escrita num registo de auditoria apenas para acréscimo na área de trabalho do cliente. O registo de auditoria não pode ser alterado ou apagado, incluindo por afka.
Conforme significa que o requisito está em vigor agora e a afka cumpre-o. Em curso significa que o trabalho começou e não está concluído. Previsto significa que o trabalho está agendado e ainda não começou.
| Norma | Estado | O que isto significa | Documentação disponível hoje |
|---|---|---|---|
| SOC 2 Type I | Em curso | O trabalho rumo ao exame está em curso. Ainda não existe nenhum relatório, e afka não afirma ter um. | Esta página; Anexo II do DPA; um questionário sob pedido. |
| SOC 2 Type II | Em curso | Um relatório Type II cobre controlos durante um período de observação. O trabalho está em curso e ainda não existe nenhum relatório. | Nenhuma. |
| ISO/IEC 27001 | Previsto | afka não detém certificado e nenhum processo de certificação está em curso. | Um mapeamento de controlos em relação aos requisitos que o comprador nomeia. |
| ISO/IEC 42001 | Previsto | afka não detém certificado para um sistema de gestão de IA e esse trabalho ainda não começou. | Secções 6 e 7; as entradas correspondentes do Anexo II. |
| GDPR (Regulamento (UE) 2016/679) | Conforme | afka é processador, o cliente é controlador. O DPA é publicado em termos padrão, contém as obrigações do Artigo 28 na íntegra e incorpora as Cláusulas Contratuais Padrão de 2021. Uma posição legal, não uma certificação. | O DPA e seus Anexos; a Política de Privacidade, que publica a lista de sub-processadores. |
| UK GDPR e Data Protection Act 2018 | Conforme | O DPA cobre o Reino Unido expressamente e incorpora o International Data Transfer Addendum (versão B1.0). | O DPA, incluindo suas eleições de Addendum. |
| CCPA e leis de privacidade dos estados dos EUA | Conforme | afka atua como prestador de serviços e não vende nem partilha informações pessoais. Termos equivalentes cobrem os estatutos de Delaware, Virginia, Colorado, Connecticut, Texas e Oregon. | O DPA (termos de prestador de serviços); a Política de Privacidade. |
| Google API Services User Data Policy, incluindo Limited Use | Conforme | Apenas âmbitos de início de sessão para o cliente Google da própria afka, mais o âmbito da aplicação Google Chat. Não é solicitado qualquer âmbito de leitura de caixa de correio. | Secção 2.6 do DPA, indicando os âmbitos e compromissos de Limited Use. |
afka não detém hoje um relatório SOC 2 de qualquer tipo, e não detém certificado ISO/IEC 27001 ou ISO/IEC 42001. Não existe atestação e nenhum relatório disponível sob acordo de confidencialidade.
O que um comprador pode ter hoje: as descrições de controlos nesta página; Anexo II do DPA, que indica onde uma medida é fornecida por um prestador de plataforma subjacente; um mapeamento desses controlos para a estrutura que o comprador nomeia; o DPA, assinado; e um questionário de segurança preenchido. Escreva para support@afka.ai.
Os espaços de trabalho são isolados na base de dados, não no código da aplicação. Cada tabela de inquilino tem segurança ao nível das linhas baseada numa afirmação de identificador comercial que um gancho de token de acesso personalizado injeta no token de acesso no início da sessão. Uma consulta feita com o token de um espaço de trabalho não pode devolver linhas de outro, portanto um erro na aplicação não se torna uma exposição entre inquilinos: o limite não é imposto pela camada que tem o erro.
Nas tabelas principais, a segurança ao nível das linhas é definida como FORCE, removendo a isenção que uma política ordinária concede ao proprietário da tabela. Essas tabelas são tarefas, execuções, aprovações, artefatos, registo de auditoria, livro de créditos, conectores, competências do espaço de trabalho, dados de monitorização de agentes e cartões proativos.
O isolamento de inquilinos é verificado automaticamente antes de qualquer alteração ser lançada.
Como defesa em profundidade, as funções do lado do servidor nunca confiam num identificador de espaço de trabalho fornecido pelo cliente: eles re-resolvem o inquilino a partir do token verificado.
As referências de ligação para contas ligadas são mantidas no cofre de segredos da plataforma de base de dados gerida: nunca em ficheiros de ambiente, nunca no pacote frontend, nunca numa variável de compilação que chegue ao navegador.
Para um conector gerido pela plataforma de conector, a concessão OAuth é mantida por essa plataforma; afka mantém apenas uma referência a ela. Desligar revoga portanto a conta na origem, através de uma chamada de API à plataforma, e afka escreve uma linha de auditoria registando-a.
As chaves de API são armazenadas como um hash SHA-256, mostrado uma vez na criação e nunca recuperável; apenas um prefixo e os últimos quatro caracteres são mantidos, para apresentação. Os âmbitos são re-intersectados com as capacidades ativas do criador em cada chamada de autenticação, portanto uma chave não pode sobreviver às permissões do seu criador, e o âmbito de gestão de chaves não pode ser concedido a uma chave.
O modelo nunca recebe uma credencial bruta; o gateway de ferramenta backend injeta-a no momento da execução. Quando um agente actua em nome do membro que ligou uma ferramenta, o token desse membro é lido do cofre por entrega e o conector publica sob o nome desse membro.
O código escrito por um modelo de linguagem não é confiável desde o momento em que existe. É executado numa microVM isolada com um kernel convidado por tarefa, destruída após a execução e nunca reutilizada entre espaços de trabalho. Cada execução obtém tokens com âmbito de curta duração em vez de segredos de longa duração.
A saída de rede da sandbox é negada por padrão.
Cada execução é limitada por limites de CPU, memória, tempo decorrido e créditos.
Cada agente tem um nível de autonomia que o cliente define e pode alterar. Em Suggest propõe trabalho e não actua até ser instruído. Em Review prepara uma acção e retém-na para aprovação. Em Auto pode executar acções nas classes de risco que o cliente lhe libertou, sujeito aos limites abaixo.
O trabalho ordinário não tem classificação de risco e nunca pede: leitura, pesquisa, redacção, actualização de estado interno. Acima dele situam-se as quatro classes de risco que o selector governa: money, gastar ou mover dinheiro; send, comunicar fora da área de trabalho; record, criar ou alterar registos numa ferramenta ligada; account, alterar definições de conta ou área de trabalho.
Acima do selector situa-se um conjunto de categorias que o selector não pode libertar. Dinheiro a sair da conta do cliente, e decisões que causam dano irreversível a uma pessoa, sempre pedem primeiro a uma pessoa nomeada. As categorias bloqueadas são reembolsos, pagamentos, transferências e decisões adversas sobre uma pessoa, com uma lista de acção nomeada: processar um cancelamento, alterar uma subscrição, uma acção de desvinculação, uma alteração de conta, gastar dinheiro. Uma segunda regra independente cobre o mesmo terreno: um conjunto de dinheiro (reembolsos, créditos, descontos, concessões de fidelização, gastos, checkout, cobrança e captura de pagamento, alterações de subscrição, realocação de publicidade) e um conjunto de pessoas (ofertas enviadas ou encaminhadas, recomendações de contratação, desvinculação, qualquer coisa marcada como adversa).
O mecanismo é um limite e não uma proibição. Uma acção bloqueada é forçada ao nível Review, portanto uma pessoa nomeada deve aprová-la antes de ser executada, e o aprovador, a acção e o alvo são escritos no registo de auditoria. Se ninguém aprovar, não é executada. Uma acção que o sistema não consegue classificar com confiança é tratada como bloqueada.
Afrouxar a autonomia é reservado ao proprietário da área de trabalho, portanto uma alteração na postura de risco é atribuível a uma pessoa nomeada. As aprovações pendentes expiram num tempo de vida e são limpas. Os limites de gastos são somados numa acção dividida em passos, portanto a decomposição não passa sob um limite. Qualquer agente em execução pode ser parado a partir da aplicação.
Todas as ações realizadas por um agente ou uma pessoa são escritas num registo de auditoria apenas para acréscimo na área de trabalho do cliente. O registo não pode ser alterado ou eliminado, incluindo por afka: uma tentativa de alterar ou eliminar uma entrada é rejeitada.
Uma linha contém o ator, a ação, o alvo, o carimbo de data e hora, o custo de crédito, o identificador de execução, uma referência à aprovação que autoriza quando foi necessária, e se o iniciador foi um humano ou um agente.
Os clientes exportam o registo por si próprios. Uma função do lado do servidor verifica o token do chamador, resolve o inquilino no servidor e verifica uma capacidade de exportação nomeada: os proprietários e administradores têm-na sempre, um membro apenas se lhe for concedida. Os formatos são CSV e NDJSON, este último para um sistema de gestão de informações e eventos de segurança. A exportação escreve a sua própria linha no registo.
A exportação não é assinada criptograficamente nem autenticada, e um cliente não deve representar uma exportação a um tribunal, a um regulador ou a uma contraparte como à prova de manipulação.
Quando a funcionalidade de reuniões está ativada, um assistente nomeado participa na chamada como participante visível e anuncia-se ao entrar. afka não entra numa chamada de forma encoberta e não oferece nenhum modo em que o fizesse.
afka transcreve; afka não grava vídeo. Não há gravação de vídeo nem biblioteca de gravações. O que é mantido é uma transcrição e resultados derivados: resumos, ações e trabalho de acompanhamento.
As transcrições de reuniões e as amostras brutas de reconhecimento de fala são eliminadas numa janela contínua de trinta (30) dias por uma limpeza automática diária. Na mesma janela, o prompt armazenado de uma tarefa e o contexto armazenado de uma aprovação são esvaziados enquanto os registos em si são mantidos. As amostras de fala encontram-se numa tabela que nem a função de base de dados anónima nem a autenticada conseguem ler.
O registo de auditoria não contém conteúdo de fala ou mensagens.
Uma entrada agendada pode ser cancelada antes da chamada; o assistente pode ser removido durante uma chamada, o que termina a transcrição; e uma chamada com a sua transcrição pode ser eliminada depois, uma eliminação que o produto recusa até o assistente ter sido removido. O consentimento é responsabilidade do cliente: algumas jurisdições exigem o consentimento de todos os participantes. O participante que se auto-anuncia não é um substituto para esse processo, como os Termos de Serviço estabelecem.
afka armazena e processa rotineiramente dados de clientes nos Estados Unidos. A computação de aplicações, ou seja, alojamento de aplicações, o worker de fundo e a entrada de voz, funcionam nos Estados Unidos, na região declarada como Oregon. A cache ativa, limitação de taxa e análise de produtos também funcionam em regiões dos Estados Unidos.
A base de dados gerida principal está localizada nos Estados Unidos, na região East US (Virgínia do Norte).
afka não oferece residência de dados da União Europeia. Para transferências fora da Área Económica Europeia, Reino Unido e Suíça, o DPA incorpora as Cláusulas Contratuais Padrão e o Aditamento do Reino Unido.
Todo o tráfego para afka é transportado através de TLS. A encriptação em repouso é fornecida pelos fornecedores de base de dados gerida, armazenamento e alojamento subjacentes. As respostas viradas para o navegador transportam estes cabeçalhos:
Uma política de segurança de conteúdo é aplicada. Juntamente com ela, uma política mais rigorosa funciona em modo apenas de relatório, comunicando violações a um ponto final dedicado, para que regras mais rigorosas sejam medidas contra tráfego real antes da aplicação; esses relatórios são eliminados a cada trinta (30) dias. Os formulários públicos são protegidos por um desafio de detecção de bots gerido na borda.
O acesso às plataformas de produção é concedido com base no princípio do menor privilégio, autenticado em cada fornecedor e revogado quando já não for necessário. Não há acesso rotineiro ao conteúdo do cliente: um membro da equipa da afka não lê o conteúdo das mensagens do cliente no curso ordinário da execução do serviço. O acesso de suporte é limitado ao que a questão levantada exige. Todas as pessoas autorizadas a processar dados dos clientes estão vinculadas por uma obrigação de confidencialidade escrita que sobrevive ao fim do seu contrato.
A chave da base de dados administrativa é utilizada apenas no servidor e nunca é exposta ao navegador ou a uma sandbox.
A autenticação única SAML 2.0 é fornecida, construída na plataforma de autenticação gerida, e funciona com qualquer fornecedor de identidade SAML 2.0. Está vinculada a um domínio da empresa que deve ser verificado antes da utilização, um domínio por espaço de trabalho.
A imposição, ou seja, desativar o início de sessão por palavra-passe para o domínio verificado, é fornecida desativada e não pode ser ativada até que uma autenticação única bem-sucedida tenha sido concluída, portanto a imposição não pode bloquear um administrador de um espaço de trabalho em que nunca funcionou. A autenticação única está disponível no plano de self-service mais elevado e nos planos empresariais, não nos planos inferiores.
A sincronização de diretório SCIM não é construída. Não existe aprovisionamento ou desaprovisionamento automatizado orientado por diretório. A remoção de uma pessoa é feita na aplicação ou, quando a imposição está ativada, no fornecedor de identidade.
afka não utiliza dados de clientes para treinar modelos de IA de uso geral. afka não vende dados de clientes nem os utiliza para publicidade ou criação de perfis comportamentais entre contextos.
Os compromissos de afka sobre o comportamento dos seus fornecedores de IA refletem os acordos contratuais em vigor com cada um deles, e um fornecedor pode alterar os seus termos unilateralmente. Se afka tomar conhecimento de que tal alteração reduziria materialmente a proteção aplicável aos dados de clientes, fornecerá aviso prévio através do processo de alteração de sub-processador na DPA, que inclui um período de aviso de trinta (30) dias, um direito de objeção e uma via para rescindir a parte afetada do serviço. A DPA também vincula afka a exigir que os seus fornecedores de IA não utilizem dados pessoais de clientes para treinar modelos de uso geral.
afka utiliza um pequeno número de fornecedores de modelos de IA sob contrato: Anthropic para os modelos de linguagem primários, em uso sempre que um agente é executado; Moonshot como nível de fallback em direto para esses modelos; OpenAI apenas para conversão de fala em texto; Voyage AI para os embeddings utilizados para indexar e recuperar conhecimento do espaço de trabalho; e Tavily para a etapa de pesquisa na web. Estes fornecedores estão nomeados na lista de sub-processadores publicada na Política de Privacidade, que faz parte da DPA, e uma alteração a essa lista é notificada com antecedência através do processo descrito acima.
Se encontrou um problema de segurança no afka, por favor informe-nos. Escreva para support@afka.ai com detalhes suficientes para o reproduzir, e o afka reconhecerá o relatório e mantê-lo-á informado enquanto é investigado e corrigido. O afka não perseguirá um investigador que comunique de boa fé, evite aceder ou destruir dados de outras pessoas, e dê ao afka uma oportunidade razoável para corrigir o problema primeiro.
O afka não executa um programa de recompensa por erros pago. O que o afka oferece é um reconhecimento rápido, uma correção real e crédito público se o desejar.
Escreva para support@afka.ai e afka enviará, sem chamada e sem processo de qualificação: o DPA em termos padrão, pronto para assinar, com o Anexo II como inventário de controlo discriminado; um mapeamento dos controlos de afka para qualquer estrutura que nomear; o seu próprio questionário de segurança preenchido; e uma resposta direta sobre qualquer controlo nesta página.
Consulte também os Termos de Serviço, que regem a autonomia, aprovações e responsabilidade pelas ações de um agente, e a Política de Privacidade. Quando esta página e o DPA diferem, o DPA prevalece.