Arquitetura empresarial de Spatial AI

A arquitetura empresarial de Spatial AI separa modelos de linguagem, mapas, dados de negócio, cálculos espaciais, permissões, ferramentas e ações para que cada tarefa permaneça na camada que consegue aplicá-la. Uma resposta fluente ainda pode mandar alguém para a filial errada. O host mantém identidade e transações. Serviços espaciais calculam a geografia. O modelo de linguagem interpreta a solicitação e explica um resultado que esses sistemas já fundamentaram.

As seções abaixo cobrem propriedade, autorização, credenciais, ferramentas, o caminho da solicitação e três padrões de implantação. Leituras relacionadas incluem Spatial AI Accuracy Evaluation e An Enterprise Spatial AI Pilot. Uma recusa correta pode ser um resultado melhor do que uma recomendação plausível que nenhum sistema de registro sustenta.

Fundamentos da arquitetura empresarial de Spatial AI

• Separe as tarefas: O modelo de linguagem interpreta e explica. Ele não é dono do estoque, das permissões, das rotas nem das transações.
• Autorize antes da recuperação: Resolva usuário, tenant, objetos e campos antes que contexto privado chegue ao modelo.
• Mantenha os fatos tipados: IDs estáveis e campos operacionais permanecem estruturados. Prosa não os substitui.
• Delimite cada ferramenta: Ações de leitura, mapa, rascunho e escrita têm regras de aprovação diferentes.
• Meça o workflow: Observe a decisão de localização e o resultado no host, não apenas tokens e latência.

O que é arquitetura empresarial de Spatial AI?

Um cliente pode perguntar qual centro de serviço consegue atender um trabalho hoje, está dentro da área contratual e acrescenta o menor tempo de viagem à rota atual. Essa frase exige uma camada de intenção, registros de cliente e contrato, dados da unidade, regras de área de serviço, um cálculo de rota e um workflow de mapa. Um sistema de produção também precisa de identidade, isolamento de tenants, limites de ferramentas, validações de ação, logs e um ponto em que uma pessoa possa aprovar uma etapa de alto impacto. Colocar todos esses trabalhos em um único prompt torna o produto difícil de proteger e de mudar. O modelo pode indicar o que deve acontecer em seguida. A aplicação das regras fica fora do modelo.

O lado esquerdo conecta um modelo diretamente a bancos de dados, roteamento e transações. O lado direito mantém identidade, dados, ferramentas espaciais, ranking e ação validada em camadas separadas. O contraste representa um padrão de arquitetura, não um benchmark da Kaleidr.

Um caminho prático se parece menos com um usuário falando com um modelo que alcança tudo e mais com uma sequência que o host consegue inspecionar. A aplicação mantém o usuário e o estado atual do mapa. Identidade e autorização são resolvidas antes da recuperação. A interpretação de intenção pede então apenas dados aprovados e cálculos espaciais. A elegibilidade remove opções inválidas antes do ranking. Uma ação validada atualiza o mapa ou o workflow, e o analytics registra se a tarefa foi concluída com sucesso. Essa sequência permite trocar modelos, provedores de mapa ou regras de ranking sem reconstruir o produto em torno de uma dependência opaca.

Qual sistema deve ser dono de cada fato?

Um workshop de arquitetura deve nomear o proprietário de cada fato crítico antes que alguém escolha um modelo. O provedor de identidade do host é dono do usuário. A aplicação host é dona da associação ao tenant, dos direitos de produto, do workflow e do resultado de negócio. Sistemas de negócio são donos da identidade da unidade, estoque, disponibilidade, preço, status de reserva e políticas. Uma fonte de localização aprovada é dona das coordenadas. O cálculo espacial é responsável por distância, tempo de viagem e ponto-em-polígono. A aplicação cliente é dona do viewport e do local selecionado. A camada de IA é responsável pela interpretação de intenção e pela explicação escrita sobre evidência fundamentada. O workflow do host é dono da transação final.

Cada coluna tem um proprietário principal. A camada de IA coordena intenção e explicação. Host e sistemas de negócio continuam sendo os sistemas de registro, e o quadro é um framework, não um inventário de produto.

Se uma equipe não consegue nomear o proprietário de um fato crítico, um assistente normalmente esconde a lacuna. A orientação da Kaleidr sobre Spatial AI fundamentada usa a mesma divisão: o modelo interpreta intenção composta, enquanto estoque, políticas, permissões e roteamento permanecem nos sistemas criados para manter esses fatos (Kaleidr, 2026). Recuperação encontra contexto. Autoridade decide qual fonte pode responder a uma pergunta factual. Um documento recuperado não é automaticamente o sistema de registro.

Por que autorizar antes de recuperar?

Um erro comum recupera dados privados, envia-os ao modelo e depois pergunta ao modelo quais linhas a pessoa pode ver. Inverta essa ordem. Autentique o usuário, resolva o tenant, resolva funções e direitos, autorize objetos, minimize campos, recupere os registros aprovados e só então encaminhe o contexto necessário. A fronteira de permissão deve ser determinística e auditável. Um modelo de linguagem não deve escolher se um gerente regional pode ver uma unidade, se um cliente pode ler o histórico de localização de outro cliente ou se um funcionário pode recuperar dados restritos do local de trabalho.

Registros privados atravessam a fronteira apenas após verificações de tenant, função, objeto e campo. O caminho inferior, que pediria a um modelo para inferir permissões a partir de um banco completo, permanece bloqueado. Credenciais da plataforma e autorização do usuário final continuam sendo verificações diferentes.

Uma credencial de plataforma pode mostrar que uma aplicação tem permissão para usar uma capacidade. Essa credencial não decide qual usuário final pode ler quais linhas. CORS, autenticação de credenciais, escopos de capacidade de API e autorização do usuário em nível de aplicação resolvem problemas distintos; misturá-los produz o tipo errado de falha (Kaleidr, 2026). O caminho de dados privados é, portanto, uma pilha de verificações, não um único token que significa tudo.

Como separar credenciais de navegador e servidor?

Um navegador pode ser inspecionado, portanto tudo que é entregue a ele deve ser tratado como visível para a pessoa que o executa. O backend é o lugar correto para segredos de longa duração, acesso a dados privados de negócio, aplicação de políticas e chamadas servidor a servidor. O navegador pode manter uma credencial publicável e segura para o cliente destinada a uma capacidade de mapa limitada. Solicitações autenticadas do produto vão ao backend do host, que aplica o contexto do usuário, acessa dados privados e chama operações espaciais ou de IA com uma credencial de servidor. Os dois ambientes de execução não devem compartilhar o mesmo segredo.

O lado do navegador foi projetado para exposição e permanece limitado a capacidades de cliente com escopo definido. O lado do servidor mantém a credencial de servidor, registros privados e autorização de usuário. As marcas de seleção são um esboço de fronteira, não uma certificação de segurança.

A documentação atual de chaves da Kaleidr define uma chave publicável para uso no navegador e uma chave de servidor para integrações backend. A chave publicável é bloqueada por origem, e o SDK a troca por uma sessão de curta duração em tempo de execução, em vez de usar essa string como bearer permanente do servidor. A chave de servidor permanece em servidores confiáveis (Kaleidr, 2026). O mesmo conjunto de documentação descreve Chat, Editor, Tile e Viewer como superfícies separadas, com entradas de attach, embed e tile que não são montadas todas da mesma maneira (Kaleidr, 2026). Siga o contrato atual de cada superfície, em vez de presumir que uma credencial e uma montagem cobrem toda a pilha.

Onde devem ficar os fatos de negócio e a geografia?

Enterprise Spatial AI é útil quando consegue raciocinar sobre fatos que um modelo público não conhece: estoque atual, elegibilidade de parceiros, capacidade da unidade, cobertura contratual, fechamentos temporários e disponibilidade em tempo real. Esses fatos pertencem aos sistemas de registro. Não peça ao modelo para memorizar um valor que pode mudar esta tarde. Não faça fine-tuning de um modelo em um campo operacional que uma consulta pode retornar. Não cole um amplo banco de dados interno em um system prompt. Interprete a solicitação, decida quais registros autorizados são necessários, recupere o conjunto mínimo, mantenha IDs estáveis e campos tipados, aplique filtros rígidos, calcule a geografia e só então explique o resultado fundamentado.

{
  "branch_id": "b_1042",
  "open_now": true,
  "inventory_status": "in_stock",
  "service_eligible": true,
  "lat": 38.91,
  "lng": -77.22
}

Um registro tipado pode ser filtrado, registrado em log, verificado quanto a permissões e passado para uma ação posterior. Uma frase dizendo que uma filial “parece aberta” e “provavelmente” tem o item não pode. A linguagem natural ainda pertence à explicação. Ela não deve substituir campos que a aplicação pode armazenar diretamente.

Cálculos espaciais merecem sua própria camada pelo mesmo motivo. Ponto-em-polígono, distância de rota, tempo de condução, tempo a pé, pertencimento à área de serviço, desvio de rota e análise de alcançável-dentro-do-tempo devem vir de um serviço geográfico quando o produto consegue calculá-los. A camada de IA pode determinar que um cálculo é necessário. O serviço espacial o executa. A explicação então diz por que essa relação importa para a solicitação. Trocar o modelo de linguagem não força a equipe a reaprender como a aplicação mede tempo de viagem ou contenção.

Restrições rígidas e preferências flexíveis devem ficar separadas. Uma solicitação de clínica pode exigir um plano aceito, horário depois das 18h, uma localização ativa e um registro ao qual o usuário tenha acesso. Apenas os candidatos que passam por essas regras devem ser classificados por tempo de condução, desvio de rota ou uma preferência declarada. A ordem é recuperação, autorização, elegibilidade, cálculo espacial, ranking e explicação. Fazer o ranking primeiro e esperar que o modelo tenha lembrado de todas as restrições esconde uma opção inválida dentro de uma lista fluente. Varejo, imóveis, reservas, locais de trabalho e redes com várias unidades podem compartilhar essa ordem porque a restrição trata de validade, não de vocabulário do setor.

Como ferramentas e ações devem ser delimitadas?

A Spatial AI agêntica torna o catálogo de ferramentas uma das fronteiras importantes. Ferramentas abertas como uma string SQL arbitrária, um comando shell ou uma URL interna de formato livre são um ambiente de execução, não uma capacidade de negócio. Prefira ferramentas estreitas com entradas e saídas conhecidas: buscar locais elegíveis, calcular tempo de viagem, ler disponibilidade da filial, mostrar lugares, solicitar uma rota ou criar um rascunho de reserva. Cada ferramenta pode ter sua própria verificação de permissão, validação, limite de taxa, linha de log e modo de falha.

Ferramentas de leitura e mapa podem ser executadas quando o chamador já está autorizado. Rascunhos criam um objeto revisável. Escritas que confirmam uma reserva, despacham trabalho ou alteram um registro aguardam um gate de política explícito. As camadas são orientação arquitetural, não uma lista fixa de permissões da Kaleidr.

Ler um registro e alterar o estado de negócio pertencem a classes de risco diferentes. Um catálogo de produção pode agrupar capacidades em leitura, mapa, rascunho e escrita. Ações de leitura e mapa de baixo impacto podem ser executadas automaticamente após a autorização. Um rascunho pode preparar uma reserva ou solicitação de serviço para revisão. Uma escrita que confirma uma reserva, despacha um veículo ou publica uma alteração pode exigir confirmação, uma segunda verificação de política e, às vezes, uma pessoa. Uma pontuação de confiança não é um sistema de permissões.

A orientação da OWASP de 2025 sobre excessive agency trata funcionalidade excessiva, permissões excessivas e autonomia excessiva como causas separadas. Ela recomenda limitar ao mínimo necessário as extensões que um agente pode chamar, preferir funções granulares em vez de abertas, exigir aprovação para ações de alto impacto e aplicar autorização nos sistemas downstream em vez de confiar no modelo para permitir a chamada (OWASP, 2025). A aplicação ainda deve validar cada chamada proposta. Para uma ação de mapa, verifique se a ação é permitida, se os IDs de lugar pertencem ao conjunto de resultados autorizado, se o usuário pode acessá-los e se os argumentos estão bem formados. Para uma escrita, aplique uma verificação mais rigorosa. Um prompt, um documento recuperado ou um resultado de ferramenta malformado não pode se tornar um bypass de autorização.

A orientação da OWASP sobre system prompts estabelece a mesma fronteira do outro lado. O system prompt não é um segredo nem um controle de segurança. Separação de privilégios e verificações de autorização não devem ser delegadas ao modelo, via prompt ou de qualquer outra forma (OWASP, 2025). Ações de mapa devem usar um vocabulário semântico, como mostrar lugares, enquadrar lugares, selecionar um lugar, desenhar uma rota ou limpar uma rota, e um adaptador determinístico deve traduzir essas ações para Mapbox, MapLibre, Google Maps ou outro renderer. O modelo não deve emitir código do renderer a cada turno.

Como o estado do mapa deve entrar na solicitação?

O estado do mapa muda o que uma pessoa quer dizer com “estes”, “ao norte daqui” ou “a segunda opção”. Um snapshot útil pode incluir limites do viewport, o ID do lugar selecionado, IDs de resultados visíveis, filtros ativos, um ID de rota atual e uma localização aprovada na precisão exigida pela tarefa. Marque quais campos estão sempre disponíveis, são opcionais, privados, aprovados pelo usuário, desatualizados, autoritativos ou inferidos. Não envie a localização precisa do dispositivo em todas as solicitações apenas porque o mapa consegue lê-la. A referência mais forte para “qual destes fica aberto até mais tarde” são os IDs estáveis do conjunto de resultados atual, não uma captura de tela. A orientação da Kaleidr sobre assistentes map-aware traça essa linha: compartilhe viewport, seleção, filtros e IDs de resultados e não peça ao modelo para inferir a aplicação a partir de pixels (Kaleidr, 2026).

Uma camada de orquestração pode decidir se a solicitação precisa de recuperação de dados de negócio, roteamento, uma ação de mapa, uma pergunta de esclarecimento ou um resumo das evidências. Essa camada pode ser orientada por modelo, por regras ou por uma combinação. Ela não deve ser a única fronteira de segurança. A orquestração pode perguntar se deve consultar disponibilidade. A autorização responde se este chamador pode recuperar disponibilidade para esses registros. A orquestração pode perguntar se deve iniciar uma reserva. A camada de transação responde se a pessoa confirmou e se a operação é válida. A divisão resiste a um erro do modelo.

O isolamento de tenant pertence ao mesmo caminho. Resolva identidade autenticada, tenant, função e objetos permitidos antes da consulta e limite a consulta a esse tenant. Não confie em um prompt dizendo que o modelo foi instruído a não mencionar outros tenants. O modelo nunca deve receber dados de outro tenant, a menos que a aplicação tenha um propósito e uma política explícitos entre tenants. Consultas com escopo de tenant, verificações de objetos, minimização de campos e logs redigidos são os controles. Uma frase no prompt não é um deles.

Como uma solicitação de produção percorre a pilha?

Uma solicitação completa pode ser desenhada em doze etapas, e nem toda solicitação precisa de todas elas. Capture o usuário autenticado, o tenant, o estado do mapa e o estado do workflow. Interprete a tarefa, as restrições geográficas, as restrições de negócio e a ação pretendida. Resolva fontes, registros, campos, ferramentas e ações permitidos antes de qualquer recuperação privada.

Recupere fatos autorizados e IDs canônicos de lugares e depois calcule distância, tempo de viagem, contenção ou pertencimento à área de serviço. Remova candidatos não autorizados, indisponíveis, fechados ou fora da área e classifique o restante. Explique o resultado fundamentado, proponha uma ação semântica de mapa ou workflow e valide essa ação fora do modelo. Execute a ação e depois registre a decisão e o resultado.

As etapas vão do estado do mapa e intenção, passando por autorização, grounding, geografia, elegibilidade e ranking, até explicação, ação proposta, validação, execução e medição. Uma solicitação simples como “mostrar este lugar” pode pular recuperação e ranking. Uma recomendação de serviço pode usar quase todo o caminho.

O comportamento em caso de falha faz parte do mesmo caminho. Se os dados de negócio não estiverem disponíveis, não invente disponibilidade. Diga que a disponibilidade não pode ser verificada no momento. Se o roteamento estiver indisponível, não alegue um ranking por tempo de viagem e rotule qualquer alternativa em linha reta como fallback. Se nenhum candidato passar pelas regras rígidas, retorne nenhum resultado em vez de relaxar silenciosamente uma restrição crítica. Se a autorização falhar, não peça ao modelo para explicar informações privadas que ele nunca recebeu. Se o modelo estiver indisponível, busca e filtros determinísticos ainda podem atender ao mapa. Se o resultado de uma ferramenta estiver malformado, rejeite-o na validação. Quando um produto não tem um modo degradado explícito, o modelo de linguagem se torna o fallback acidental para infraestrutura ausente.

A aprovação humana segue o impacto, não uma única regra para todos os botões. Mostrar três lugares públicos é de baixo impacto. Confirmar um compromisso, despachar um veículo, alterar o registro de uma unidade ou enviar uma reserva paga não é. Classifique busca, recuperação e prévia de rota como baixo impacto. Uma preferência salva ou um rascunho como impacto médio. Uma compra, um despacho, uma escrita operacional ou uma mudança de permissão como alto impacto. Execução automática, confirmação do usuário e uma aprovação separada podem então corresponder à classe. O AI Risk Management Framework do NIST é voluntário e foi criado para incorporar confiabilidade ao design, desenvolvimento, uso e avaliação de produtos de IA. A mesma página do NIST informa que o AI RMF 1.0 está sendo revisado (NIST, 2023). O framework serve de contexto para as próprias decisões de risco do produto e não é uma lista de controles da Kaleidr.

Onde fica o plano de controle?

O caminho da solicitação lida com o trabalho em tempo real: usuário, autorização, recuperação, ferramentas espaciais, modelo, ação e resposta. O plano de controle decide como esse caminho pode ser executado. Credenciais, escopos, escolha de modelo, prompts, políticas de ferramentas, configuração de fontes de dados, limites de taxa, ambientes, suítes de avaliação, feature flags e configurações de auditoria ficam ali. Separar os dois permite que uma equipe mude políticas sem reescrever cada fluxo conversacional. Desativar uma ferramenta de escrita não deve exigir uma nova interface. O plano de controle é um padrão de arquitetura para essas configurações, e o diagrama não afirma que um único produto forneça cada caixa.

A linha superior contém configuração: credenciais, escopos, modelos, prompts, políticas de ferramentas, fontes de dados, limites, avaliação, flags e configurações de auditoria. A linha inferior é a solicitação em tempo real. A política aponta para as etapas que governa, permitindo que uma equipe altere uma regra sem reescrever o caminho.

A observabilidade deve acompanhar a decisão, não apenas a conta de tokens. Eventos úteis incluem intenção resolvida, autorização aprovada ou negada, recuperação concluída, candidatos removidos por elegibilidade, cálculo espacial concluído, ranking concluído, resposta sem resultado, ferramenta proposta, ferramenta rejeitada, ação de mapa executada, lugar selecionado e workflow concluído. Esses nomes são um padrão a ser projetado, não uma lista que uma plataforma emite automaticamente. As perguntas que eles respondem são práticas. Os erros vêm da resolução de lugares ou do ranking? As pessoas estão rejeitando uma lista válida? Um mercado produz mais resultados vazios? As chamadas de ferramentas falham por permissões ou por argumentos malformados? A pessoa concluiu a tarefa do host depois de selecionar um lugar? O núcleo do AI RMF do NIST diz que conjuntos de testes, métricas e detalhes sobre as ferramentas usadas durante teste, avaliação, verificação e validação devem ser documentados (NIST, 2023). Para Spatial AI, os testes documentados devem cobrir a decisão geográfica e de negócio, não apenas a frase gerada.

Analytics espacial e resultados do host respondem perguntas diferentes, e a arquitetura deve uni-los com IDs estáveis. O Kaleidr Analytics atualmente descreve dashboards de alcance, visualizações e engajamento, localização e atividade do público, sessões, visualizações e interações por mapa e padrões espaciais (Kaleidr, 2026). Reservas, compras, leads qualificados, despachos e serviços concluídos permanecem nos sistemas do host que são donos deles. Um ID de recomendação pode apontar para um ID de lugar selecionado, depois para um ID de workflow do host e então para o resultado. O material público de analytics não diz que toda conversão de negócio é capturada automaticamente.

Quais são os três padrões de implantação?

Três padrões cobrem a maioria das implantações empresariais, e nenhum deles é universalmente o melhor. Um assistente de mapa público serve para turismo, descoberta, mapas editoriais e exploração de eventos. O mapa no navegador usa uma capacidade de cliente publicável, IA consciente do mapa, dados de lugares públicos ou aprovados e ferramentas espaciais, e então retorna uma ação de mapa. A fronteira de dados é mais simples porque o workflow é majoritariamente público. Um assistente de negócio autenticado serve para portais de clientes, seleção de lojas considerando estoque, imóveis, redes de parceiros e instalações privadas. O navegador acessa um login do host e um backend do host, que aplica autorização de tenant e objeto antes que dados privados, ferramentas espaciais e a explicação voltem ao mapa. Um agente espacial com ações de negócio serve para reservas, despacho e workflows operacionais. O caminho adiciona uma proposta de ferramenta tipada, validação determinística, confirmação quando o impacto exigir, o sistema de transações e uma auditoria do resultado. Esse terceiro padrão altera o estado de negócio e, por isso, carrega a governança mais rígida.

O padrão público permanece em locais públicos aprovados. O padrão autenticado mantém registros privados atrás do host. O padrão de ação adiciona validação e confirmação antes de uma transação. Os cartões de locais de exemplo na figura são ilustrativos, não resultados medidos da Kaleidr.

Onde a Kaleidr se encaixa nessa arquitetura?

A Kaleidr atualmente descreve Enterprise como infraestrutura de location intelligence para equipes de produto, com inference APIs, ranking, analytics e superfícies SDK que um host pode adicionar (Kaleidr, 2026). A documentação para desenvolvedores lista quatro superfícies em um SDK. Chat adiciona interação de IA a um mapa que o host já opera. Editor incorpora edição de mapas dentro de um produto. Tile serve um basemap projetado. Viewer publica um mapa para incorporação. A documentação atual de Chat lista Mapbox, MapLibre e Google Maps como caminhos de integração para esse mapa operado pelo host (Kaleidr, 2026). O host mantém usuários finais, autenticação, autorização de tenant, sistemas privados de negócio, regras de workflow, transações e resultados de negócio. A Kaleidr adiciona superfícies espaciais selecionadas e não substitui os sistemas que permanecem autoritativos na pilha do host.

A linha do host mantém usuários, autorização de tenant, workflows, sistemas privados, transações e resultados. Chat, Editor, Tile e Viewer ficam ao lado de APIs de plataforma e Analytics. Os rótulos de credenciais seguem a separação pública navegador/servidor, e a figura não mostra um segredo real.

Quais erros ficam escondidos até a produção?

Conectar o modelo diretamente a todos os sistemas cria privilégios excessivos e torna difícil encontrar a camada que está falhando. Tratar um prompt como a camada de autorização falha pelo mesmo motivo: um prompt pode orientar a redação, mas não consegue permitir ou negar um registro de forma determinística. Enviar todo o banco de dados interno para o contexto viola a minimização. Misturar filtros rígidos com ranking permite que um local inelegível sobreviva dentro de uma média. Pedir ao modelo para estimar uma distância que o serviço espacial consegue calcular substitui um cálculo por fluência. Uma ferramenta irrestrita, ou uma ferramenta de escrita que herda a política de uma ferramenta de leitura, dá a uma recomendação a autoridade de uma transação. Tratar o mapa como imagem descarta os IDs estáveis de que o próximo turno precisa. Monitorar apenas latência e custo de tokens deixa de fora resolução de lugares, elegibilidade, roteamento, ranking, falhas de ferramentas e o resultado do host. Um benchmark do modelo, sozinho, não consegue dizer que o workflow montado está pronto.

O rascunho público inicial do framework TEVV-Athlon do NIST, NIST AI 200-2, anunciado em 7 de agosto de 2026, com comentários abertos até 6 de outubro de 2026, descreve avaliação como evidência de que um sistema atende a objetivos individuais ou organizacionais, com medição adaptada à aplicação e ao impacto no mundo real, incluindo sistemas agênticos (NIST, 2026). O documento é um rascunho que busca contribuições. O rascunho não é uma lista de controles da Kaleidr. Para esta arquitetura, o contexto de avaliação é a decisão dependente de localização: intenção, autorização, grounding, geografia, elegibilidade, ranking, ferramentas, ações, tratamento de falhas e resultado do host.

Como a arquitetura empresarial de Spatial AI se torna um gate de lançamento?

Antes de um piloto avançar para produção, confirme os proprietários. O usuário é autenticado onde o workflow exige, e a associação ao tenant é resolvida fora do modelo. Cada campo crítico tem uma fonte autoritativa, a recuperação privada acontece antes da inferência, os campos são minimizados e IDs estáveis sobrevivem à passagem. Serviços geográficos executam os cálculos que o produto afirma realizar, e as tolerâncias usadas na avaliação são documentadas. As ferramentas são estreitas, leitura e escrita são separadas, argumentos são validados e ações de alto impacto podem ser confirmadas e auditadas. Credenciais de navegador e servidor permanecem separadas, escopos permanecem limitados e ambientes permanecem separados. A equipe consegue ver a cadeia de decisão e ligar uma seleção de lugar a um resultado do host. Dados indisponíveis, conjuntos de candidatos vazios e modos degradados são explícitos, e operações críticas falham de modo fechado em vez de inventar um fato. Explore o Kaleidr Enterprise para APIs de spatial intelligence, ranking, analytics e superfícies SDK ao lado da pilha que o produto já opera. Leia a documentação para desenvolvedores da Kaleidr para os contratos atuais de Chat, Editor, Tile, Viewer, chaves e escopos antes da implementação.

Perguntas frequentes

O que é arquitetura empresarial de Spatial AI?

Arquitetura empresarial de Spatial AI é o design de sistema que conecta modelos de linguagem, mapas, serviços geográficos, dados de negócio, permissões, ferramentas, ações e analytics, mantendo cada responsabilidade na camada que consegue aplicá-la.

Um modelo de linguagem deve ter acesso direto a um banco de dados de negócio?

Normalmente não como uma interface irrestrita. Autorize o usuário atual, recupere o mínimo de registros de que a tarefa precisa, mantenha os campos estruturados e exponha ferramentas estreitas. Acesso aberto ao banco de dados transforma o modelo no mecanismo de permissões.

Pelo que o modelo de linguagem deve ser responsável?

O modelo é adequado para intenção em linguagem natural, orquestração entre capacidades aprovadas e explicação de um resultado fundamentado. Autorização, transações, verdade de negócio e cálculos geográficos permanecem nos sistemas projetados para essas funções.

Qual é a diferença entre autenticação da plataforma e autorização do usuário?

A autenticação da plataforma estabelece que uma aplicação pode usar uma capacidade da plataforma. A autorização do usuário decide qual pessoa ou tenant pode acessar um registro ou executar uma ação de negócio. Uma verificação não substitui a outra.

Spatial AI deve usar retrieval-augmented generation?

A recuperação pode fornecer documentos ou registros relevantes. Recuperação sozinha não estabelece autoridade. Estoque, disponibilidade, preço, permissões e pertencimento a áreas de serviço devem permanecer vinculados aos seus sistemas de registro e a regras determinísticas.

Como as ferramentas de Spatial AI devem ser protegidas?

Use funções estreitas, permissões mínimas, autorização no contexto do usuário, validação de argumentos, limites de taxa, monitoramento e uma aprovação independente para ações de alto impacto. Não trate o modelo nem o system prompt como mecanismo de autorização.

Ações de Spatial AI devem exigir aprovação humana?

A aprovação acompanha o impacto. Ações de mapa de baixo risco, como exibir lugares, podem ser executadas automaticamente. Compras, reservas, despachos, escritas administrativas e mudanças de permissão podem exigir confirmação explícita ou aprovação separada.

Como um assistente de mapa deve usar o mapa atual?

Passe estado estruturado como limites do viewport, IDs de lugares selecionados, filtros ativos, IDs de resultados visíveis, IDs de rota e uma localização na precisão necessária à tarefa. Não exija que o modelo infira o estado da aplicação a partir de uma captura de tela quando existe estado estruturado.

Spatial AI pode trabalhar com um mapa existente?

Sim. Uma camada de Spatial AI pode se conectar a um mapa e a uma aplicação que o host já opera. A documentação atual do Kaleidr Chat descreve a conexão de Spatial AI conversacional a instâncias de Mapbox, MapLibre ou Google Maps operadas pelo host.

Como uma equipe deve avaliar a arquitetura antes de escalar?

Avalie o workflow montado: intenção, autorização, grounding, cálculos geográficos, elegibilidade, ranking, explicação, ferramentas, ações, tratamento de falhas e resultados de negócio. Um benchmark genérico de modelo de linguagem não substitui esse teste.

Referências

1. Kaleidr. Grounded Spatial AI for Business Data. https://kaleidr.com/blog/grounded-spatial-ai-business-data
2. Kaleidr. Map API Authentication. https://kaleidr.com/blog/map-api-authentication
3. Kaleidr. Get an API Key. Publishable browser keys and server keys. Accessed September 30, 2026. https://docs.kaleidr.com/get-an-api-key
4. Kaleidr. Introduction. Chat, Editor, Tile, and Viewer in one SDK. Accessed September 30, 2026. https://docs.kaleidr.com/
5. OWASP Gen AI Security Project. LLM06:2025 Excessive Agency. Accessed September 30, 2026. https://genai.owasp.org/llmrisk/llm062025-excessive-agency/
6. OWASP Gen AI Security Project. LLM07:2025 System Prompt Leakage. Accessed September 30, 2026. https://genai.owasp.org/llmrisk/llm072025-system-prompt-leakage/
7. Kaleidr. How to Build a Map-Aware AI Assistant. https://kaleidr.com/blog/how-to-build-a-map-aware-ai-assistant
8. National Institute of Standards and Technology. AI Risk Management Framework. Voluntary framework for trustworthiness in design, development, use, and evaluation. Released January 26, 2023. Page states that AI RMF 1.0 is being revised. Accessed September 30, 2026. https://www.nist.gov/itl/ai-risk-management-framework
9. National Institute of Standards and Technology. AI RMF Core. Measure 2.1: test sets, metrics, and details about the tools used during TEVV are documented. Accessed September 30, 2026. https://airc.nist.gov/airmf-resources/airmf/5-sec-core/
10. Kaleidr. Map Engagement and Location Analytics. Accessed September 30, 2026. https://kaleidr.com/analytics
11. Kaleidr. Location Intelligence APIs and Map SDK. Accessed September 30, 2026. https://kaleidr.com/enterprise
12. Kaleidr. Chat. Attach AI to a host-run Mapbox, MapLibre, or Google Maps instance. Accessed September 30, 2026. https://docs.kaleidr.com/chat
13. National Institute of Standards and Technology. The TEVV-Athlon Framework for Evaluating AI Systems. NIST AI 200-2, initial public draft. Announced August 7, 2026; comments through October 6, 2026. https://www.nist.gov/artificial-intelligence/ai-research/tevv-athlon-framework-evaluating-ai-systems
14. Kaleidr. Spatial AI Accuracy Evaluation. https://kaleidr.com/blog/spatial-ai-accuracy-evaluation
15. Kaleidr. An Enterprise Spatial AI Pilot Before Scaling. https://kaleidr.com/blog/enterprise-spatial-ai-pilot-before-scaling

@misc{kaleidr_grounded_architecture_2026,
  title  = {Grounded Spatial AI for Business Data},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/blog/grounded-spatial-ai-business-data}
}

@misc{kaleidr_map_api_auth_2026,
  title  = {Map API Authentication},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/blog/map-api-authentication}
}

@misc{kaleidr_get_api_key_2026,
  title  = {Get an API Key},
  author = {{Kaleidr}},
  year   = {2026},
  note   = {Accessed September 30, 2026},
  url    = {https://docs.kaleidr.com/get-an-api-key}
}

@misc{kaleidr_docs_intro_2026,
  title  = {Introduction},
  author = {{Kaleidr}},
  year   = {2026},
  note   = {Accessed September 30, 2026. Chat, Editor, Tile, and Viewer},
  url    = {https://docs.kaleidr.com/}
}

@misc{owasp_llm06_2025,
  title  = {LLM06:2025 Excessive Agency},
  author = {{OWASP Gen AI Security Project}},
  year   = {2025},
  note   = {Accessed September 30, 2026},
  url    = {https://genai.owasp.org/llmrisk/llm062025-excessive-agency/}
}

@misc{owasp_llm07_2025,
  title  = {LLM07:2025 System Prompt Leakage},
  author = {{OWASP Gen AI Security Project}},
  year   = {2025},
  note   = {Accessed September 30, 2026},
  url    = {https://genai.owasp.org/llmrisk/llm072025-system-prompt-leakage/}
}

@misc{kaleidr_map_aware_2026,
  title  = {How to Build a Map-Aware AI Assistant},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/blog/how-to-build-a-map-aware-ai-assistant}
}

@misc{nist_ai_rmf_2023,
  title  = {AI Risk Management Framework},
  author = {{National Institute of Standards and Technology}},
  year   = {2023},
  note   = {Released January 26, 2023. Accessed September 30, 2026. Page states AI RMF 1.0 is being revised},
  url    = {https://www.nist.gov/itl/ai-risk-management-framework}
}

@misc{nist_ai_rmf_core_2023,
  title  = {AI RMF Core},
  author = {{National Institute of Standards and Technology}},
  year   = {2023},
  note   = {Measure 2.1. Accessed September 30, 2026},
  url    = {https://airc.nist.gov/airmf-resources/airmf/5-sec-core/}
}

@misc{kaleidr_analytics_architecture_2026,
  title  = {Map Engagement and Location Analytics},
  author = {{Kaleidr}},
  year   = {2026},
  note   = {Accessed September 30, 2026},
  url    = {https://kaleidr.com/analytics}
}

@misc{kaleidr_enterprise_architecture_2026,
  title  = {Location Intelligence APIs and Map SDK},
  author = {{Kaleidr}},
  year   = {2026},
  note   = {Accessed September 30, 2026},
  url    = {https://kaleidr.com/enterprise}
}

@misc{kaleidr_chat_docs_2026,
  title  = {Chat},
  author = {{Kaleidr}},
  year   = {2026},
  note   = {Accessed September 30, 2026},
  url    = {https://docs.kaleidr.com/chat}
}

@techreport{nist_ai_200_2_2026,
  title       = {The TEVV-Athlon Framework for Evaluating AI Systems},
  author      = {{National Institute of Standards and Technology}},
  institution = {National Institute of Standards and Technology},
  number      = {NIST AI 200-2},
  year        = {2026},
  note        = {Initial public draft, announced August 7, 2026},
  url         = {https://www.nist.gov/artificial-intelligence/ai-research/tevv-athlon-framework-evaluating-ai-systems}
}