O Provisionamento da Databricks Substitui Espaços de Trabalho Compartilhados por uma Máquina de Vendas Preparada para Agentes

A Databricks substituiu um modelo pressionado de espaços de trabalho compartilhados por um sistema de provisionamento que atende mais de 5.000 usuários ativos em três nuvens. O novo sistema de provisionamento da Databricks fornece aos engenheiros de campo ambientes isolados que expiram automaticamente, em vez de deixar administradores coordenarem o acesso manualmente.

A empresa chama a aplicação interna de Field Engineering Vending Machine, ou FEVM. Sua chegada cria uma tensão clara entre dois modelos de infraestrutura. Um pede que as pessoas compartilhem ambientes de longa duração e negociem conflitos. O outro cria recursos temporários e governados para cada tarefa, incluindo tarefas iniciadas por agentes de IA.

Essa mudança importa porque a Databricks agora tem mais de 7.000 pessoas em sua organização de go-to-market. Engenheiros de campo frequentemente precisam de controle administrativo para criar demonstrações, reproduzir problemas de clientes e testar recursos em prévia. Espaços de trabalho compartilhados se tornaram mais difíceis de governar à medida que esse grupo cresceu de menos de 1.500 pessoas três anos antes.

A história imediata é uma reformulação da infraestrutura interna. A história maior é sobre quem controla o provisionamento de nuvem quando agentes podem solicitar recursos, implantar código, carregar dados e executar fluxos de trabalho. A FEVM transforma intenção em linguagem natural em infraestrutura de nuvem, mas também aproxima a ação administrativa de software autônomo.

O Provisionamento da Databricks Passa de Capacidade Compartilhada para Ambientes Temporários

A Databricks tornou a infraestrutura isolada a unidade de trabalho padrão para sua organização de engenharia de campo.

No modelo anterior, uma pequena coleção de espaços de trabalho compartilhados atendia grande parte da organização de campo. A manutenção manual permanecia administrável quando a engenharia de campo tinha menos de 1.500 pessoas. Esse arranjo se tornou instável à medida que a organização mais ampla de go-to-market cresceu para mais de 7.000 funcionários.

Esse grupo também tem requisitos de acesso incomuns. Um espaço de trabalho corporativo típico pode depender de alguns administradores que gerenciam muitos usuários. Engenheiros de campo da Databricks frequentemente precisam de controle em nível de administrador, porque seu trabalho envolve configuração, testes e demonstrações específicas para clientes.

Vários engenheiros trabalhando no mesmo ambiente podem interferir uns nos outros. Uma alteração feita para uma demonstração pode afetar outro engenheiro que se prepara para uma reunião com cliente. Limites de catálogo, banco de dados e carga de trabalho também se tornam restrições operacionais imediatas quando muitas equipes compartilham capacidade.

A atribuição de custos enfraquece ao mesmo tempo. Um espaço de trabalho compartilhado pode revelar o consumo total sem mostrar claramente qual engenheiro, cenário de cliente ou experimento o gerou. Atividades inesperadas passam então a exigir investigação manual em logs e sistemas.

A FEVM muda a unidade operacional de um espaço de trabalho compartilhado por um grupo para um ambiente associado a uma finalidade e um responsável. Um engenheiro escolhe um modelo, provedor de nuvem e região. A solicitação pode incluir adições como notebooks, recursos Lakebase ou ativos empacotados.

O sistema então provisiona o ambiente e registra seu ciclo de vida. Ambientes de criação têm uma duração padrão de 90 dias, enquanto outros tipos de recurso podem usar diferentes configurações de tempo de vida. Uma política de tempo de vida define quando um recurso temporário deve expirar e ser removido.

Segundo o detalhado relato da FEVM da empresa, notificações do Slack informam quando o provisionamento termina, quando a expiração se aproxima e quando a exclusão ocorre. Essa visibilidade transforma a limpeza de uma responsabilidade informal em um evento registrado pelo sistema.

A FEVM também gerencia alguns recursos de forma independente. Um catálogo pode sobreviver depois que seu espaço de trabalho associado desaparece e, em seguida, se reconectar a outro espaço de trabalho na mesma região. Essa separação evita que o ciclo de vida de um recurso controle desnecessariamente tudo ao seu redor.

A mudança importante, portanto, não é apenas um formulário de solicitação mais rápido. A Databricks colocou criação, propriedade, expiração e exclusão dentro de um único processo governado. Esse processo se aplica tanto quando uma pessoa usa a interface quanto quando um agente chama o serviço subjacente.

A Escala Transformou o Acesso Administrativo no Problema Central

A pressão veio de uma força de trabalho que precisava de amplo controle sem aceitar a desordem que esse controle normalmente cria.

As equipes de engenharia de campo operam de forma diferente da maioria dos grupos internos de negócios. Elas precisam responder rapidamente a situações de clientes, muitas vezes com configurações que não podem esperar por uma equipe central de plataforma. Restringir cada engenheiro a uma função de usuário limitada atrasaria o trabalho que depende do teste de recursos administrativos.

No entanto, conceder acesso amplo a milhares de pessoas dentro de espaços de trabalho compartilhados cria seu próprio gargalo. Cada usuário ganha flexibilidade, mas cada mudança aumenta a chance de conflito, propriedade pouco clara ou interferência acidental. Administradores de plataforma passam então mais tempo coordenando atividades que o modelo de acesso deveria acelerar.

A FEVM resolve essa contradição ao transferir o controle para ambientes isolados. Os engenheiros mantêm a capacidade de configurar infraestrutura, enquanto modelos mantidos centralmente definem as condições iniciais. O isolamento limita o raio de impacto de cada experimento sem obrigar cada solicitação a passar por uma fila manual de tickets.

A Databricks afirma que o sistema já lidou com mais de 2.600 implantações ativas em AWS, Microsoft Azure e Google Cloud. Também processou quase 1.200 solicitações de provisionamento em um único dia da BuildCon, um evento interno de engenharia.

Esses números vêm da Databricks e não receberam validação independente. Ainda assim, mostram o padrão de carga de trabalho para o qual a empresa projetou o sistema. A demanda chega em picos, envolve muitos usuários e cria recursos que não devem permanecer ativos indefinidamente.

O sistema tinha mais de 5.000 usuários ativos quando a Databricks publicou seu relato em 23 de julho de 2026. A empresa disse que não havia encontrado um problema de escalabilidade naquele momento. Essa afirmação descreve a experiência interna, não uma garantia de desempenho para implantações de clientes.

Essa escala também muda o significado do autoatendimento de infraestrutura. Uma pequena equipe de plataforma pode tolerar exceções informais e suporte direto. Milhares de usuários exigem modelos repetíveis, propriedade explícita, limpeza automática e registros que administradores possam inspecionar posteriormente.

Portais comparáveis para desenvolvedores, incluindo sistemas baseados em Backstage, frequentemente apresentam serviços e modelos aprovados por meio de um catálogo compartilhado. Provedores de nuvem também oferecem catálogos de serviços para infraestrutura padronizada. A FEVM segue esse amplo padrão de autoatendimento, mas o adapta ao trabalho de campo da Databricks e a solicitações orientadas por agentes.

A pressão competitiva, portanto, mira menos um fornecedor específico do que o modelo manual de ambientes compartilhados. Equipes internas de plataforma que continuam usando tickets e sandboxes de longa duração agora enfrentam uma alternativa visível. Elas podem disponibilizar ambientes temporários aprovados sem abrir mão de políticas centralizadas.

No entanto, infraestrutura temporária não elimina o trabalho de governança. Ela desloca esse trabalho para modelos, controles de identidade, políticas de ciclo de vida e registros de auditoria. Engenheiros de plataforma precisam manter esses componentes cuidadosamente, pois mais usuários podem acioná-los com maior frequência.

A Databricks reconhece essa realidade operacional. A empresa afirma que integrar fluxos de trabalho Git, identidade corporativa, Slack, e-mail e Terraform multicloud exigiu mais esforço do que criar a interface da aplicação. Essa admissão é mais instrutiva do que a metáfora da máquina de vendas.

Uma caixa de solicitação refinada é apenas a ponta visível. O trabalho difícil fica por trás dela, onde a identidade deve acompanhar as solicitações, as permissões devem permanecer limitadas e a exclusão deve ocorrer sem remover recursos que deveriam persistir.

O Mecanismo Conecta a Intenção do Usuário à Infraestrutura Multicloud

A FEVM importa porque trata um caso de uso, e não uma especificação bruta de espaço de trabalho, como a solicitação de provisionamento.

Um engenheiro não precisa começar listando cada recurso necessário. O usuário descreve um objetivo, como preparar uma demonstração de serviços financeiros ou reproduzir um problema de suporte. A FEVM mapeia esse objetivo para um modelo validado e expõe opções de configuração para nuvem e região.

A aplicação usa um frontend React e um backend Python implantado por meio de Databricks Apps. A plataforma de aplicações executa aplicações dentro da Databricks e as conecta a serviços como Unity Catalog, SQL e autenticação OAuth.

O Terraform executa o provisionamento de nuvem subjacente. Terraform é um sistema de infraestrutura como código, o que significa que as equipes definem recursos em configurações versionadas, em vez de criá-los por etapas manuais desconectadas. Seu fluxo de trabalho declarativo pode gerenciar recursos por APIs de provedores em AWS, Azure e Google Cloud.

Quando a FEVM recebe uma solicitação, seleciona o modelo Terraform relevante e o envia a um executor baseado em Git. O fluxo de trabalho ajusta permissões, provisiona as adições solicitadas e registra os recursos resultantes. Esse projeto mantém a experiência do usuário separada da camada de execução da infraestrutura.

O Lakebase armazena o estado e a configuração do sistema. Lakebase é o serviço Postgres gerenciado da Databricks, e sua documentação inclui o estado de aplicações para agentes de IA entre seus usos compatíveis. A FEVM registra o que cada recurso é, quem o possui, por que existe e quando expira.

Esse registro de estado é essencial. Um agente pode solicitar várias operações dependentes muito mais rápido do que uma pessoa navegando por consoles separados. Sem um inventário confiável, a automação pode criar infraestrutura mais rapidamente do que os administradores conseguem compreendê-la ou removê-la.

A interface também oferece um catálogo de modelos. Exemplos descritos pela Databricks incluem ambientes serverless estáveis na AWS, configurações multicloud e ambientes com escalonamento automático do Lakebase já configurado. Os modelos permitem que equipes centrais codifiquem padrões aprovados antes que as solicitações cheguem.

Essa estrutura cria um caminho controlado da intenção à ação:

• Uma pessoa ou agente declara o caso de uso.

• A FEVM seleciona um padrão de recursos aprovado.

• O solicitante escolhe parâmetros permitidos.

• O Terraform cria os recursos de nuvem.

• O Lakebase registra a propriedade e o estado do ciclo de vida.

• As notificações expõem eventos de provisionamento e exclusão.

• As políticas de expiração removem a infraestrutura temporária.

Cada etapa reduz a ambiguidade. A linguagem natural pode expressar o objetivo, mas o modelo aprovado determina qual infraestrutura o sistema realmente criará. Esse limite distingue o acesso governado por agentes de um chatbot irrestrito conectado a credenciais de nuvem.

O mecanismo também oferece suporte a fluxos de trabalho compostos. A Databricks descreve um cenário no qual um engenheiro pede a um agente que crie um espaço de trabalho, implante Databricks Asset Bundles locais, carregue dados do Amazon S3 e execute um script de hidratação para um dashboard.

Um script de hidratação preenche um novo ambiente com os dados ou a configuração necessários. Da perspectiva do usuário, uma solicitação pode acionar toda a sequência. Da perspectiva da equipe de plataforma, cada ação ainda precisa de ferramentas autenticadas, parâmetros aprovados e estado observável.

É aqui que o Model Context Protocol entra no desenho. O MCP é um padrão aberto que permite que aplicações de IA se conectem a ferramentas e fontes de dados por meio de uma interface comum. A visão geral oficial do MCP o descreve como uma forma de agentes acessarem fluxos de trabalho externos e executarem ações.

A Databricks afirma que o FEVM usa o MCP como ponto central de controle para interfaces de chat, serviços externos e agentes. Habilidades do Claude publicadas centralmente podem contornar a interface gráfica e chamar APIs do FEVM. Um arquivo de habilidade informa ao agente como acionar o fluxo de trabalho aprovado.

Isso não significa que o modelo de linguagem provisiona infraestrutura diretamente. O agente envia uma solicitação a um serviço controlado, que aplica modelos e regras de identidade. Terraform, fluxos de trabalho do Git e o backend do FEVM executam o trabalho consequente.

Essa separação é a decisão central de engenharia. A linguagem natural lida com a intenção, enquanto sistemas determinísticos de infraestrutura lidam com a execução. O modelo pode ajudar a selecionar e coordenar ferramentas, mas não substitui o gerenciamento de estado nem os controles de ciclo de vida que as sustentam.

O acesso orientado a agentes aumenta o custo de um modelo ruim

A mesma abstração que facilita solicitações seguras pode disseminar um erro de configuração entre milhares de usuários.

A Databricks afirma que novos modelos são avaliados, reforçados e testados repetidamente. A empresa também observa que sua equipe opera sob exceções de segurança porque o FEVM automatiza ações administrativas contra infraestrutura real de backend.

Essa divulgação identifica a principal incerteza. O FEVM concentra autoridade por trás de uma interface conveniente. Se permissões, mapeamento de identidade ou um modelo estiverem errados, um agente poderá acionar o caminho defeituoso de forma consistente e em alta frequência.

Um processo manual introduz atrito, mas esse atrito às vezes dá a um operador tempo para perceber uma solicitação incomum. A automação elimina essa pausa. Em seu lugar, é preciso usar verificações de políticas, parâmetros restritos, limites de aprovação e registros completos de auditoria.

A qualidade dos modelos, portanto, torna-se uma fronteira de segurança. Um modelo pode decidir quais caminhos de rede existem, quais identidades recebem acesso, quais dados se tornam disponíveis e quais recursos sobrevivem à exclusão. A qualidade da revisão importa tanto quanto a velocidade de implantação.

A linguagem natural adiciona outra incerteza. Uma solicitação pode estar incompleta, ser ambígua ou se basear em uma suposição incorreta. O FEVM precisa traduzir a intenção em um caso de uso conhecido sem ampliar silenciosamente o escopo do que foi solicitado.

A Databricks não publicou medições detalhadas de solicitações malsucedidas, negações de políticas, seleção incorreta de modelos, erros de limpeza ou tempo médio de provisionamento. Essas medidas revelariam mais sobre a qualidade operacional do que apenas o número de implantações.

A empresa também não descreveu com que frequência humanos precisam intervir depois que um agente inicia um fluxo de trabalho de várias etapas. Uma solicitação de infraestrutura bem-sucedida ainda pode produzir um ambiente inutilizável se o carregamento de dados, a implantação de pacotes ou scripts posteriores falharem.

A visibilidade de custos exige escrutínio semelhante. O FEVM associa recursos a proprietários e finalidades, o que melhora a atribuição. No entanto, o relato público não fornece gastos em nuvem antes e depois, reduções de recursos ociosos ou o custo de operar a própria plataforma.

A expiração automática pode reduzir infraestrutura abandonada, mas um padrão de 90 dias ainda é longo o bastante para que recursos caros se acumulem. Diferentes tipos de carga de trabalho precisam de limites distintos. As políticas de extensão também precisam de revisão para que ambientes temporários não se tornem permanentes por meio de renovações rotineiras.

O suporte multicloud amplia o desafio. AWS, Azure e Google Cloud têm sistemas de identidade, cotas, serviços regionais e modos de falha diferentes. Uma interface comum de solicitação pode esconder essas diferenças dos usuários, mas a equipe da plataforma ainda precisa administrá-las.

Os limites da plataforma representam outro ponto de pressão. A Databricks observa limites rígidos envolvendo recursos do Unity Catalog e do Lakebase. O gerenciamento centralizado do ciclo de vida ajuda a evitar esses tetos, mas não os elimina. A demanda ainda pode superar a capacidade disponível ou criar contenção regional.

O próprio Lakebase oferece suporte a estado transacional de aplicações, escalonamento automático e ramificações isoladas, segundo sua documentação do Postgres. A confiabilidade do FEVM ainda depende de como seu próprio esquema, processos de reconciliação e lógica de recuperação usam esses recursos.

A Databricks afirma que a equipe reestruturou o FEVM duas vezes, incluindo mudanças no esquema do banco de dados, no frontend e no gerenciamento de estado. Esse histórico sugere que o desenho exigiu iteração significativa. Também aconselha cautela contra tratar a arquitetura atual como uma implementação de referência simples.

A empresa usou IA para acelerar a programação, mas afirma que humanos mantiveram o controle sobre a arquitetura. Essa divisão faz sentido para um sistema que gerencia infraestrutura privilegiada. Código gerado pode acelerar a implementação, enquanto a revisão humana continua responsável por limites e recuperação de falhas.

A escala relatada do FEVM prova que funcionários querem provisionamento mais rápido. Ainda não prova que solicitações originadas por agentes ofereçam a mesma confiabilidade, segurança ou controle de custos que solicitações humanas cuidadosamente revisadas. Essas alegações exigem dados operacionais de prazo mais longo e métricas mais claras.

O verdadeiro adversário é o espaço de trabalho compartilhado de longa duração

O FEVM substitui coordenação por isolamento, mas apenas ao tornar a política central da plataforma mais importante.

Espaços de trabalho compartilhados inicialmente parecem eficientes. As equipes reutilizam infraestrutura comum, evitam configurações repetidas e mantêm recursos em um único local visível. Essas vantagens se enfraquecem quando a maioria dos usuários precisa de amplo controle e o trabalho com clientes exige configurações incompatíveis.

Na escala atual da Databricks, ambientes compartilhados transformam coordenação em trabalho oculto. Engenheiros precisam evitar colisões, administradores precisam rastrear propriedade e equipes precisam decidir quem pode alterar recursos comuns. Uma demonstração crítica pode depender de outro usuário não modificar o mesmo ambiente.

O provisionamento isolado inverte essa relação. Cada engenheiro recebe um ambiente criado para sua finalidade sem negociar com todos os demais. A equipe da plataforma padroniza modelos e regras de ciclo de vida em vez de mediar conflitos individuais de espaço de trabalho.

A mudança também altera como empresas devem avaliar a utilização. Um ambiente compartilhado pode parecer eficiente porque muitas pessoas usam um único espaço de trabalho. No entanto, essa métrica ignora tempo de espera, desvio de configuração, demonstrações malsucedidas e esforço de investigação.

Ambientes temporários podem parecer menos eficientes porque o sistema cria mais espaços de trabalho. Ainda assim, podem gerar menos desperdício operacional quando a propriedade é clara e a limpeza ocorre automaticamente. A Databricks não publicou dados de custo suficientes para estabelecer esse resultado, mas o desenho o torna mensurável.

Esse padrão se assemelha a ambientes efêmeros de desenvolvimento usados na entrega de software. As equipes criam um ambiente limpo para uma ramificação, teste ou revisão e depois o removem quando o trabalho termina. O FEVM aplica um ciclo de vida semelhante à engenharia de campo de dados e IA.

O elemento agentivo intensifica o argumento a favor do isolamento. Uma pessoa que trabalha por uma interface gráfica geralmente realiza operações em sequência. Um agente pode coordenar várias ferramentas e criar diversos recursos a partir de uma única instrução.

Colocar essas operações em um espaço de trabalho compartilhado e lotado aumentaria a probabilidade de interação inesperada. Um ambiente isolado dá ao fluxo de trabalho um local delimitado. Também oferece aos administradores uma unidade mais clara para atribuição, expiração e exclusão.

No entanto, o isolamento pode criar proliferação se o inventário e a limpeza falharem. A resposta não é apenas isolamento. É isolamento combinado com estado, propriedade, notificações e aplicação de ciclo de vida gerenciados centralmente.

É por isso que o rótulo de máquina de venda automática é útil e incompleto ao mesmo tempo. Uma máquina de venda automática apresenta um pequeno catálogo e entrega um item previsível. O FEVM também precisa autenticar o solicitante, interpretar a intenção, criar infraestrutura distribuída, monitorar limites e, por fim, reverter cada mudança.

A plataforma se assemelha mais a um plano de controle interno do que a uma aplicação simples. Um plano de controle é a camada de gerenciamento que decide quais recursos devem existir e coordena seu ciclo de vida. O FEVM fica entre usuários ou agentes e as nuvens subjacentes.

Essa posição dá à Databricks um campo de testes direto para suas próprias tecnologias de aplicação, banco de dados, governança e agentes. Também cria um incentivo para apresentar o uso interno bem-sucedido como evidência para a plataforma mais ampla.

Os leitores devem separar essas duas alegações. O FEVM pode ser uma solução interna crível sem provar que toda empresa consegue reproduzi-lo facilmente. A organização de campo da Databricks conta com conhecimento especializado, acesso profundo à plataforma e autoridade para manter integrações entre sistemas corporativos.

Outras empresas podem depender de plataformas de dados, provedores de identidade, sistemas de tickets, mecanismos de políticas e contas de nuvem separados. Seu trabalho de integração pode exceder o esforço necessário para criar a interface de usuário. O próprio relato da Databricks afirma que essa integração gerou grande parte da dificuldade e do valor de engenharia do FEVM.

A lição não é que toda empresa precise de uma máquina de venda automática idêntica. É que infraestrutura conduzida por agentes exige uma fronteira de serviço governada. Espaços de trabalho compartilhados de longa duração e credenciais ad hoc se tornam mais difíceis de defender quando agentes de software podem iniciar fluxos de trabalho complexos.

Três sinais mostrarão se o FEVM está pronto para a era agentiva

O próximo teste é se a Databricks consegue ampliar o acesso de agentes preservando segurança, limpeza e resultados operacionais previsíveis.

O primeiro sinal é a expansão planejada da interface de linguagem natural do FEVM. A Databricks quer que engenheiros descrevam situações de clientes enquanto o sistema identifica infraestrutura adequada. Um melhor tratamento da intenção fortaleceria o argumento de que o provisionamento por caso de uso pode substituir a especificação manual.

A evidência útil não será outra demonstração de uma solicitação bem-sucedida. A Databricks deveria informar com que frequência a interface seleciona o modelo correto, pede esclarecimentos, rejeita solicitações não suportadas ou exige correção humana.

Baixas taxas de correção apoiariam o modelo orientado a agentes. Classificações erradas frequentes mostrariam que uma busca de catálogo continua mais segura do que linguagem aberta para ações de infraestrutura privilegiada.

O segundo sinal é a integração mais ampla do MCP para acesso baseado em ferramentas. A Databricks afirma que entregar essa integração é uma de suas próximas prioridades. O MCP permitiria que mais clientes de agentes alcancem o FEVM por meio de uma interface comum de ferramentas, em vez de exigir um fluxo de trabalho gráfico dedicado.

A questão central é como o FEVM delimita autoridade entre esses clientes. Forte propagação de identidade, ferramentas restritas, aprovações claras e trilhas de auditoria completas reforçariam o desenho. Credenciais amplas ou delegação pouco clara o enfraqueceriam.

Equipes de segurança também devem observar se as ações de agentes continuam distinguíveis de seus patrocinadores humanos. Um registro de auditoria útil deve conectar o funcionário, a sessão do agente, o modelo selecionado, a finalidade solicitada, os recursos resultantes e a exclusão posterior.

O terceiro sinal é a expansão pela organização mais ampla de go-to-market. Mais usuários testarão se os modelos permanecem compreensíveis fora do público original de engenharia de campo. Eles também criarão novos padrões de carga de trabalho e demandas de suporte.

Números de adoção, por si só, não resolverão a questão. As medidas mais fortes são sucesso no provisionamento, tempo até um ambiente utilizável, taxas de negação de políticas, limpeza de recursos expirados, custo por caso de uso e frequência de intervenção humana.

A Databricks pode fortalecer seu argumento ao publicar esses resultados operacionais ao longo do tempo. Pode enfraquecê-lo se se concentrar apenas em totais de usuários ativos e implantações, deixando falhas, custos e exceções de segurança sem explicação.

Para desenvolvedores, o FEVM mostra como agentes podem atuar por meio de ferramentas de infraestrutura sem receber acesso ilimitado à nuvem. Para compradores corporativos, ele oferece um teste concreto para a governança de agentes: toda ação deve ter um responsável, uma finalidade, um caminho de política e uma regra de expiração.

Profissionais do conhecimento devem se importar porque o mesmo padrão chegará a outros sistemas empresariais. Agentes solicitarão acesso, montarão ambientes de projeto, recuperarão contexto e coordenarão ferramentas. A qualidade da camada de controle terá mais importância do que a fluência da interface de chat.

Equipes que desenvolvem fluxos de trabalho semelhantes também precisam de documentação duradoura fora do serviço de provisionamento. Uma base de conhecimento pesquisável pode preservar decisões sobre templates, descobertas de incidentes e contexto operacional para engenheiros que revisam ações de agentes.

O provisionamento da Databricks já opera em uma escala interna incomum, mas sua fase mais consequente ainda está por vir. Observe se as solicitações em linguagem natural permanecem delimitadas, se o acesso via MCP preserva a identidade e se uma adoção mais ampla melhora os resultados sem ampliar os riscos.

A questão prática para todas as equipes de plataforma agora está clara: sua infraestrutura consegue explicar quem solicitou cada recurso, por que ele existe e quando desaparecerá? Se um agente não puder operar dentro desses limites, um provisionamento mais rápido apenas cria incerteza mais rapidamente.