configurando agentes

pré-requisito: chave de LLM da organização

antes de criar um agente, a organização precisa ter configurado ao menos uma chave de API de um provedor de modelo de linguagem, em configurações → chaves LLM. a datablixt segue o modelo BYOK (bring your own key, traga sua própria chave) — a organização usa a chave e o provedor de sua escolha, entre várias opções (Anthropic, OpenAI, Google, DeepSeek, Mistral, Groq, Cohere, Azure OpenAI). isso dá ao cliente controle direto sobre custo e sobre qual provedor de IA seus dados atravessam.

criando um agente

1. acesse a seção de agentes da organização.
2. defina um nome e um slug (identificador único dentro da organização).
3. opcionalmente, escreva uma descrição de propósito do agente (ex.: "agente do time financeiro").

4. escolha o modo de implantação, que rotula o nível de sensibilidade esperado para esse agente:

   modo	indicado para
   cloud standard	uso geral, sem restrição adicional de sensibilidade
   cloud secure	dados que exigem cuidado extra, mas ainda podem usar um provedor de IA em nuvem
   on-premise	cenários onde o processamento deve permanecer o mais próximo possível do perímetro da organização

5. conceda acesso a um ou mais workspaces — sem essa concessão, o agente não enxerga nenhum dado.

concedendo acesso a workspaces

para cada workspace concedido a um agente, é possível controlar dois tipos de consulta:

• consulta estruturada (ledger) — permite ao agente consultar as tabelas do lakehouse daquele workspace via sql, para responder perguntas quantitativas ("quantos", "qual o total de", "quais os últimos").
• consulta semântica (vector) — habilita a busca por similaridade sobre conteúdo não-estruturado do workspace, voltada para perguntas mais interpretativas.

um agente pode ter diferentes combinações desses dois tipos de acesso, workspace a workspace — por exemplo, acesso total de consulta estruturada ao workspace de vendas, mas nenhum acesso ao workspace de RH.

conceda apenas o necessário

siga o princípio de menor privilégio: conceda a um agente apenas os workspaces que ele realmente precisa consultar para cumprir seu propósito. isso reduz a superfície de exposição caso o agente seja usado de forma indevida ou mal configurado.

token de serviço

cada agente possui um token de serviço próprio, usado para integrações programáticas (por exemplo, embutir o agente em um sistema interno). o token pode ser regenerado a qualquer momento — a regeneração invalida imediatamente o token anterior.

ativando e desativando

um agente recém-criado fica com status ativo por padrão. é possível desativá-lo a qualquer momento (por exemplo, durante uma manutenção ou revisão de configuração) sem precisar excluí-lo — um agente inativo recusa novas conversas até ser reativado.