Marcos Ribeiro Senior Software Engineer, Strattum A reunião técnica avança bem até alguém da segurança fazer a pergunta que trava o resto: onde exatamente o dado da nossa empresa vai ficar? A partir daí a conversa deixa de ser sobre o que a plataforma faz e passa a ser sobre de quem é a conta de nuvem em que ela roda. É essa decisão que separa os dois modelos de deploy de uma camada de contexto: o BYOC, sigla de bring your own cloud, em que a plataforma sobe na conta da própria empresa, e o modelo hospedado, em que o fornecedor provisiona e opera essa conta.
No modelo hospedado, o fornecedor abre uma conta de nuvem dedicada ao cliente e opera tudo lá dentro. Do lado da empresa existe um endereço de console e um login, sem conta para abrir e sem orçamento de nuvem para aprovar.
No BYOC a plataforma roda na conta da empresa. O fornecedor entrega o pacote de infraestrutura, o time do cliente aplica na conta dele, e a operação segue com o fornecedor a partir dali.
O resto decorre dessa escolha: quem paga a fatura da nuvem, de quem são as políticas de rede e segurança que valem por cima do ambiente, e quem precisa estar na mesa para o ambiente subir.
Cada cliente tem a própria instalação dedicada. Nada de banco, grafo, índice ou fila compartilhada entre empresas. É a mesma versão do mesmo software, na mesma disposição, nos dois casos.
O que roda dentro dela é um Company Brain, a camada que conhece a empresa: quais dados existem, onde vivem, como se relacionam e quem pode ver o quê. São três peças. Grafo de conhecimento com as entidades do negócio. Ontologia dando significado a cada termo naquela empresa. Camada semântica traduzindo a pergunta em consulta com a permissão certa. Esse contexto é servido aos modelos por um protocolo aberto de conexão entre modelos e fontes de dado, o MCP.
Manter um produto só foi escolha deliberada. Com edição reduzida de um lado, a decisão de infraestrutura passaria a limitar o que a empresa consegue fazer com o próprio contexto.
Dentro da instalação existem quatro lugares onde dado fica: o banco relacional com metadados e estado, o grafo de entidades, o índice vetorial da busca semântica e o lake com dado bruto e tratado. No BYOC os quatro ficam na conta do cliente.
É essa a diferença que política interna e regulador costumam exigir por escrito. Quando a norma diz que o dado precisa estar em conta da própria organização, o modelo hospedado não atende, por mais dedicado que o ambiente seja. A pergunta é de política, e quem responde é jurídico, compliance ou segurança.
Com a conta sendo da empresa, as regras da casa valem por cima do ambiente, e o time audita ali do mesmo jeito que já audita o resto daquela conta.
Essa é a confusão mais cara da conversa, porque muita empresa descarta o BYOC achando que vai herdar um sistema para manter.
A linha de responsabilidade fica mais para baixo do que se supõe. O cliente cuida da conta de nuvem, aplica a infraestrutura na primeira vez, aprova mudança e paga a nuvem. Instalar e atualizar a plataforma, monitorar a saúde do ambiente e responder a incidente continuam com o fornecedor nos dois modelos.
A aplicação inicial é um pacote Terraform. O time do cliente revisa o plano, vê o que vai ser criado na conta e então aplica. Instalador proprietário ficou de fora por escolha: quem responde pela conta depois que todo mundo sai da call precisa conseguir ler o que subiu.
Três caminhos costumam ser confundidos num só, e separá-los responde a maior parte das perguntas do time de rede.
As pessoas da empresa usam a plataforma pelo navegador, em HTTPS, com a identidade corporativa que já usam. Esse caminho não passa pelo fornecedor em momento nenhum.
O fornecedor opera por uma conexão que o próprio ambiente abre para fora e mantém. Por ela sobem métrica de saúde, a versão que está rodando e se a última tarefa de operação deu certo. Registro de negócio, conteúdo de tabela ou documento, log de aplicação e credencial não atravessam. Como a conexão nasce de dentro, não existe porta de entrada aberta para a operação do dia a dia.
Uma pessoa do fornecedor só entra para investigar incidente, sob autorização do cliente, com credencial nominal e registro. O acesso é revogável, e a plataforma continua rodando depois do corte.
A primeira decide sozinha na maioria dos casos. O dado precisa ficar numa conta da própria empresa? Se sim, o caminho é BYOC, e a conversa técnica seguinte é sobre como fazer esse modelo caber.
A segunda: existe alguém que cuide da conta de nuvem? Se não, o modelo hospedado é o que não tem pré-requisito do lado do cliente.
A terceira: a empresa tem compromisso de consumo com a nuvem para abater? Se sim, o BYOC tende a sair melhor, porque o custo da plataforma trabalha contra um compromisso que já existe.
No BYOC o ciclo interno entra no prazo. Abrir conta, liberar acesso e aprovar a mudança são passos do cliente, e são eles que definem quando o ambiente sobe. Como a conta continua sendo da empresa, uma política nova ou um bloqueio de saída criado depois afeta o ambiente.
No modelo hospedado as políticas de nuvem da casa não se aplicam, porque a conta não é da empresa, e o acesso é pelo console, sem entrar na nuvem por baixo. Nos dois, trocar de região depois é remontar o ambiente.
Nenhum dos dois resolve o problema anterior. Sem sistema de origem confiável, não existe o que ligar no grafo, e a ordem entre a camada de contexto e os agentes de IA pesa mais no resultado do que a escolha de conta de nuvem. Onde a plataforma roda se decide depois de quais fontes ela vai consultar.
Antes de comparar fornecedor por preço, leve duas perguntas: onde fica cada um dos lugares em que o dado é armazenado, e quem escreve a regra de permissão. Se a resposta depender de copiar a base para o ambiente de quem vende, a escolha de deploy foi feita sem a empresa participar.
Se você está montando o questionário de segurança de um projeto de IA este trimestre, me chama aqui que eu comento o recorte.
Fale com um especialista da Strattum sobre BYOC, deploy hospedado e o Company Brain da sua empresa.