GitLab Duo Self-Hosted passa a rodar modelos via Microsoft Foundry em ambiente próprio

O GitLab anunciou em 22 de setembro de 2026 a expansão do GitLab Duo Self-Hosted para suportar modelos implantados através do Microsoft Foundry, segundo reportagem da InfoQ. Na prática, isso significa que organizações passam a poder rodar os recursos de IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → do GitLab Duo (Code Suggestions, chat, fluxos agênticos) contra modelos hospedados dentro do próprio ambiente Azure↳Azure76 conteúdosDeploy de Azure Stream Analytics job com CI/CD usando Azure PipelinesDevSecOps · mai 2019Azure – Como criar uma base de dados SQL no Microsoft Azure pronta para ser utilizadaData · abr 2019Azure Static Web Apps com Vue.js e Visual Studio CodeDevSecOps · out 2023Ver tudo em DevSecOps → escolhido pelo cliente, em vez de depender da infraestrutura de modelos gerenciada pelo GitLab.

A integração cobre famílias de modelos como GPT (OpenAI), Claude (Anthropic), Llama (Meta) e Mistral, todos acessíveis via catálogo do Microsoft Foundry. O ponto central não é apenas "mais um modelo suportado": é a possibilidade de escolher provedor, local de implantação e caminho dos dados de forma independente da ferramenta de desenvolvimento.

Como fica a arquitetura

Segundo a InfoQ, o desenho técnico tem três peças: uma instância self-managed do GitLab, um AI Gateway também self-hosted do GitLab, e um ou mais endpoints de modelo hospedados via Microsoft Foundry. O Gateway funciona como intermediário entre o GitLab Duo e os modelos selecionados, em vez de amarrar cada recurso do Duo a um provedor específico de IA.

Um detalhe relevante para quem arquiteta esse tipo de ambiente é a seleção de modelo por funcionalidade. É possível usar, por exemplo, um modelo voltado a código para Code Suggestions, outro modelo para cargas de trabalho agênticas, e um modelo menor (e mais barato) para tarefas de alto volume. Trocar o modelo por trás de uma dessas funções não exige reformular o fluxo de trabalho do GitLab em si.

O trade-off que a InfoQ aponta

A reportagem destaca um ponto que costuma ficar de fora do discurso comercial de IA self-hosted: dar à organização controle sobre modelos e infraestrutura desloca responsabilidade para os times de engenharia e plataforma. Passa a ser trabalho interno gerenciar implantação de modelos, capacidade, rede, credenciais, disponibilidade e ciclo de vida dos modelos, além de manter o próprio ambiente GitLab.

Há ainda um risco operacional específico citado pela InfoQ: disponibilidade de modelo no catálogo do Microsoft Foundry não equivale automaticamente a compatibilidade com o GitLab Duo. O catálogo do Foundry pode mudar mais rápido que a matriz de modelos suportados pelo GitLab, o que obriga as equipes a verificar compatibilidade nas duas pontas antes de trocar de modelo em produção.

Onde isso se encaixa frente a GitHub Copilot e Bedrock

A InfoQ traça uma comparação direta com outras plataformas do mercado. O GitHub Copilot também vem ampliando suporte a múltiplos modelos subjacentes, mas sua experiência padrão continua fortemente integrada ao serviço gerenciado do GitHub. Já plataformas como Amazon Bedrock e o próprio Microsoft Foundry oferecem infraestrutura multi-modelo, mas não substituem uma plataforma DevSecOps integrada como o GitLab: elas resolvem a camada de modelo, não a camada de fluxo de desenvolvimento, revisão de código e pipeline.

O movimento do GitLab, segundo a reportagem, se encaixa numa tendência mais ampla do mercado de deixar de tratar ferramentas de desenvolvimento com IA e modelos de fundação como um serviço único e empacotado. O GitLab passa a se posicionar como uma camada de controle agnóstica a modelo: ele cuida do fluxo de trabalho do desenvolvedor e dos recursos de IA, enquanto a organização decide qual modelo roda por baixo.

O que muda para quem trabalha com dados sensíveis no Brasil

Para equipes brasileiras sob LGPD↳LGPD14 conteúdosComo utilizar a LGPD com o objetivo de conformidade e inovação?Gestão Dev & TI · out 2021LGPD coloca pressão inédita nos responsáveis pela tecnologia das empresasData · ago 2021Proteção de dados: LGPD é sancionada e começa a valerData · set 2020Ver tudo em Gestão Dev & TI →, ou operando em setores regulados como financeiro, saúde e órgãos públicos, a discussão de onde o modelo roda e por onde trafegam prompts e trechos de código deixou de ser secundária. Times que hoje evitam adotar Copilot ou Duo em sua forma gerenciada por não conseguirem garantir que código-fonte e prompts não saiam do país, ou não saiam da rede corporativa, ganham com essa expansão uma rota concreta: manter o GitLab self-managed, subir o AI Gateway internamente e apontar para modelos rodando dentro de uma região do Azure sob controle direto da própria empresa.

Na prática, isso não resolve sozinho a questão de soberania de dados: o Azure ainda é infraestrutura de nuvem pública, e a organização precisa negociar região de datacenter, contratos e configuração de rede junto à Microsoft. O que a arquitetura descrita pela InfoQ resolve é o ponto de decisão sobre credenciais, caminho de rede e ciclo de vida do modelo passar a estar nas mãos do time de plataforma da empresa, não do GitLab.

Isso também muda o cálculo de custo e operação para arquitetos e líderes técnicos: adotar esse caminho significa somar à equipe a responsabilidade de gerenciar disponibilidade e capacidade dos modelos no Foundry, além do que já se gasta mantendo uma instância self-managed do GitLab. Para organizações pequenas ou sem equipe de plataforma dedicada, esse é um custo real de entrada que a versão gerenciada do GitLab Duo (ou o Copilot padrão) não exige.

O que ainda fica em aberto

A InfoQ não detalha prazos de disponibilidade regional específicos para o Brasil, nem lista quais regiões do Azure já suportam essa configuração combinada com o GitLab AI Gateway. Também não há, na reportagem, benchmark de latência ou custo comparando essa rota self-hosted com o uso da infraestrutura de modelos gerenciada pelo próprio GitLab. Para times avaliando a migração, a checagem de compatibilidade entre o catálogo do Foundry e a matriz de modelos suportados pelo GitLab Duo continua sendo, segundo a própria reportagem, um passo manual que precisa ser repetido a cada atualização de qualquer um dos dois lados.

Fonte: InfoQ