A plataforma é instalada dentro da sua própria conta de nuvem.

A Nexa Intelligence é executada como um conjunto de workers, filas, armazenamentos de objetos e Durable Objects dentro de uma infraestrutura que você possui. O Cloudflare é o substrato padrão porque toda a plataforma é nativa do Cloudflare. AWS, Azure e local seguem o mesmo modelo em um fornecedor diferente. Sua equipe de TI instala o Cloud Harness. Nós operamos dentro dele. Os dados nunca saem do seu perímetro para serem processados.

Esta página cobre o que é instalado, quem gerencia o quê, o que cruza seu perímetro e como a implantação difere por fornecedor.

O Cloud Harness é o pacote de infraestrutura que se torna sua implantação. No Cloudflare, são sete workers, dois buckets R2, várias classes de Durable Objects e um pequeno conjunto de filas. Na AWS, é a mesma topologia mapeada em Lambda, S3, DynamoDB e SQS. No Azure, são Functions, Blob Storage, Cosmos DB e Service Bus. Local, é a mesma topologia no Kubernetes com Postgres, MinIO e NATS.

Sua equipe provisiona a conta. Nós fornecemos os scripts de implantação, a configuração Wrangler ou Terraform e o guia de instalação. Uma vez que o Harness esteja ativo, sua conta contém cada parte da infraestrutura que a plataforma toca. Não existe um ambiente separado controlado pela Nexa pelo qual seus dados passam.

Operamos o Harness sob contrato assinado. Sua TI mantém as chaves. Obtemos o acesso necessário para executar o enriquecimento, os painéis e as superfícies de agentes, com escopo para os ambientes que operamos.

Dois serviços vivem fora da sua conta: o provedor LLM (Anthropic) e o provedor de voz (ElevenLabs). Todas as demais partes do sistema rodam dentro da sua conta, incluindo o data lake, os workers de enriquecimento, o armazenamento de fatos, os painéis e os endpoints de agentes.

A chamada Anthropic é vinculada por um contrato de não treinamento em todos os planos. Enterprise também executa não retenção: nenhum conteúdo do cliente persiste na Anthropic além da requisição. A ElevenLabs opera não retenção em todos os planos e todos os níveis. O áudio original não deixa rastro no provedor de voz após o término da chamada. Consulte a lista de subprocessadores para os dados exatos que cada parceiro vê.

Chamadas de entrada são autenticadas na borda. Webhooks carregam uma assinatura HMAC que é verificada contra um segredo armazenado na sua conta. Superfícies do operador carregam um bearer token cujo escopo é codificado na credencial. Não há segredo compartilhado entre a Nexa e sua conta além das credenciais que sua TI nos emite.

O Cloudflare é o substrato padrão porque a plataforma é nativa do Cloudflare. O Harness é implantado como sete workers (operations, canvas, ingestion, engine, query, r2ops, docs), dois buckets R2 (o data lake e o armazenamento de artefatos de matriz) e um conjunto de classes de Durable Objects que mantêm o estado por matriz. As filas transportam trabalho assíncrono entre o worker de ingestão e o motor de enriquecimento.

Cada wrangler.toml define workers_dev = false para que as URLs *.workers.dev retornem 404. Apenas os domínios personalizados na sua conta servem tráfego. O worker do motor não tem nenhuma superfície pública. Ele é acessado por meio de consumidores de fila e service bindings de outros workers na sua conta. Não há caminho de entrada da internet para o worker que chama o LLM.

Ser nativo do Cloudflare significa que o ancoramento regional é uma mudança de configuração em vez de uma re-arquitetura. Os buckets R2 podem ser ancorados nas jurisdições eu ou fedramp por meio do binding de bucket. Os Durable Objects aceitam dicas de localização que os posicionam em uma região especificada. Consulte a seção 06 para a configuração de residência de dados.

A implantação AWS mapeia a topologia do Harness nos primitivos AWS equivalentes. Workers se tornam funções Lambda. Buckets R2 se tornam buckets S3 com isolamento por política de bucket entre o data lake e o armazenamento de artefatos de matriz. Durable Objects se tornam tabelas DynamoDB com chaves de escopo por linha. Filas se tornam SQS, com o EventBridge gerenciando fan-out.

Os segredos residem no AWS Secrets Manager, com escopo por função. Chaves KMS são emitidas por ambiente. A política IAM em cada Lambda a restringe aos buckets, tabelas e filas de que ela realmente precisa. O Lambda que chama a Anthropic não pode gravar no data lake. O Lambda que ingere webhooks não pode sobrescrever artefatos de matriz. A mesma separação de credenciais que se aplica no Cloudflare se aplica na AWS.

Fornecemos o módulo Terraform. Sua TI executa o apply. A propriedade da conta, o faturamento e o root IAM ficam com você.

A implantação Azure usa Azure Functions para a camada de workers, Blob Storage para o data lake e o armazenamento de artefatos de matriz, Cosmos DB para as tabelas de estado por matriz e Service Bus para a camada de filas. O Key Vault mantém os segredos. As identidades gerenciadas delimitam o acesso de cada Function aos recursos sobre os quais opera.

As implantações Azure são comuns em verticais reguladas. O Harness é entregue com os modelos de política Azure necessários para as configurações de residência da Loi 25 Quebec e do GDPR. Os grupos de recursos podem ser ancorados a uma região, e as contas Cosmos DB podem ser bloqueadas em uma única região sem replicação entre regiões.

Os clientes locais executam o Harness no Kubernetes. Workers se tornam implantações de contêiner. O armazenamento se torna MinIO com a mesma separação de dois buckets das variantes de nuvem. O estado por matriz se torna um esquema Postgres com segurança em nível de linha com chave no identificador de matriz. As filas se tornam NATS JetStream.

O local é a configuração para clientes com requisitos explícitos de residência de dados que nenhuma nuvem pública consegue atender, ou que já operam uma plataforma Kubernetes privada auditada por sua equipe de segurança. As mesmas chamadas de parceiros se aplicam: HTTPS de saída para Anthropic e ElevenLabs sob os mesmos contratos de não treinamento e não retenção. Se essas chamadas também forem proibidas por política, a implantação opera em modo air-gapped com inferência local e síntese de voz local. A contrapartida é a qualidade do agente de entrevista e o custo por conversa.

O armazenamento e o processamento podem ser ancorados a uma jurisdição no momento da implantação. No Cloudflare, é o sinalizador de jurisdição do bucket R2 mais as dicas de localização dos Durable Objects. Na AWS, é a região do bucket S3 e da função Lambda. No Azure, é a região do grupo de recursos. Local, é a localização física do cluster.

Para clientes com requisitos de residência na UE, cada parte da infraestrutura pode ser ancorada em regiões europeias. Para clientes no setor público canadense ou no Quebec sob a Loi 25 du Québec, as regiões canadenses de cada fornecedor estão disponíveis. O guia de implantação lista os IDs de região exatos que usamos por jurisdição.

Dentro da sua conta, a Nexa opera o Harness. Isso significa que implantamos releases, executamos resposta a incidentes, monitoramos observabilidade, ajustamos o pipeline de enriquecimento contra seu corpus, calibramos as meias-vidas por dimensão e entregamos patches. Não exportamos seus dados. Não executamos treinamento sobre eles. O caminho de dados fica dentro do perímetro que você possui.

A fronteira operacional é nomeada no contrato. Sua TI controla as chaves, o faturamento e as credenciais root. Nosso acesso tem escopo para as superfícies operacionais de que precisamos. Os logs de auditoria das ações do operador ficam na sua conta, onde sua equipe de segurança os revisa.

Se você encerrar o relacionamento com o fornecedor, a implantação continua funcionando na sua conta sem nós. Consulte Independência de Dados para a garantia de continuidade.