A arquitetura de uma empresa nativa de IA

Está se formando uma postura de liderança em torno da IA que parece menos "impulsionar a adoção" e mais preparar o terreno.

Nem toda organização está pronta para colocar agentes em produção. Nem todo caso de uso faz sentido. E sim, há hype. Mas líderes que acreditam que um futuro autônomo está chegando já estão fazendo uma pergunta mais concreta:

Este post é nossa resposta atual. Vamos cobrir a lacuna de produção que as empresas estão enfrentando, os dois modos de falha que continuamos vendo, e as camadas arquiteturais que acreditamos que uma empresa nativa de IA precisa - começando com infraestrutura de contexto, porque muda tudo acima dela.

A lacuna de produção

2025 deixou o contraste difícil de ignorar: IA pode parecer ótima em configurações controladas, mas os ganhos não se transferem automaticamente para sistemas maduros - grandes codebases, workflows desorganizados e ambientes regulados.

As evidências apontam na mesma direção. Em uma tarefa greenfield controlada, desenvolvedores usando Copilot completaram o trabalho ~55,8% mais rápido. Em um teste randomizado com desenvolvedores experientes trabalhando em seus próprios repositórios familiares, permitir assistência de IA os tornou ~19% mais lentos.

Essa diferença é a lacuna de produção: a parte difícil não é conseguir que um modelo faça algo uma vez. É fazer o comportamento repetível, auditável, seguro e previsível em custos enquanto tanto a superfície da ferramenta quanto a organização crescem.

E uma vez que você vê isso claramente, a questão empresarial muda de "Qual modelo?" para "Que infraestrutura transforma IA em uma capacidade operacional?"

O que dá errado quando empresas tentam operacionalizar IA

A história em voz alta de 2025 foram novos modelos, agentes, frameworks e promessas. A história mais silenciosa aconteceu dentro das empresas: equipes tentando tornar a IA parte das operações diárias e repetidamente enfrentando as mesmas restrições em torno de controle de acesso, debugging e custos.

É por isso que o ano produziu tanto demos impressionantes quanto resultados de produção decepcionantes. Muita "transformação de IA" ficou presa como experimentação orientada por orçamento, sem um caminho credível para confiabilidade.

Quando as equipes avançam, três problemas tendem a aparecer juntos:

Essas pressões geralmente empurram as organizações para um de dois modos de falha:

Em ambos os caminhos, você obtém atividade, mas as melhorias não se compõem. A composição requer uma configuração onde as equipes podem se mover rápido sem contornar a governança, e as equipes de plataforma podem aplicar políticas sem se tornarem o gargalo.

Então, como é essa configuração?

Nossa tese: o que precisa ser verdadeiro

Acreditamos que a composição de IA em empresas requer:

Diferentes empresas desenharão os limites de forma diferente. Mas se você está perdendo os dois primeiros, escalar software agêntico tende a estagnar (muita centralização) ou se espalhar (muita fragmentação).

Isso importa agora porque o ecossistema está convergindo para um substrato compartilhado para a camada (1).

Por que agora: a convergência do MCP

Em 2024, MCP parecia "um protocolo que algumas pessoas usam para conectar ferramentas." No final de 2025, é cada vez mais um substrato compartilhado no qual as principais plataformas estão convergindo.

Três sinais tornaram a direção difícil de ignorar:

• Anthropic doou o MCP para a Linux Foundation da nova Agentic AI Foundation, colocando-o explicitamente sob governança neutra.
• O Apps SDK da OpenAI é construído em MCP, e o quickstart deixa claro que MCP é como aplicativos expõem ferramentas ao ChatGPT.
• Google anunciou suporte oficial do MCP em serviços do Google e Google Cloud, com uma história de governança corporativa (registro/hub + logging de auditoria/IAM).

A implicação: interoperabilidade está se tornando exigência básica, e o trabalho difícil se move para cima: como você governa e opera o acesso a ferramentas em tempo de execução.

Governança não é mais opcional (e não é apenas uma preocupação do time de segurança)

À medida que os agentes se movem de "sugerir" para "fazer", a governança deixa de ser um documento de política e se torna infraestrutura de tempo de execução.

Isso se alinha com o framework de AI TRiSM do Gartner: governança, monitoramento e controles operacionais como parte da execução de sistemas de IA. E o Gartner também foi explícito sobre o lado do risco, prevendo que até 2030, mais de 40% das empresas experimentarão incidentes de segurança ou conformidade ligados à "IA sombra" não autorizada.

Então a questão empresarial se torna prática: Onde aplicamos permissões, trilhas de auditoria e controles de custo — se não dentro de cada aplicativo individual? É para isso que a infraestrutura de contexto serve.

Requisito 1: Infraestrutura de contexto governada
A fundação

Em escala, "conectar o agente às ferramentas" se torna um problema de sistemas:

• Proliferação de conexões: M servidores MCP × N agentes se torna M×N integrações, cada uma com sua própria autenticação, configuração e modos de falha.
• Lacunas de observabilidade: quando algo quebra, você não consegue responder "o que foi executado, onde, por quê e quanto custou?"
• Lacunas de governança: permissões acabam duplicadas ou inconsistentes entre aplicativos; trilhas de auditoria são parciais.
• Inchaço de descoberta de ferramentas: à medida que as superfícies de ferramentas crescem, enviar ingenuamente definições de ferramentas para todos fica caro e pode degradar o desempenho.

É isso que queremos dizer com fundação: centralizar preocupações transversais que você não deveria reconstruir dentro de cada aplicativo - SSO e identidade, aplicação de política, trilhas de auditoria, roteamento, estratégias de tempo de execução, atribuição de custo e debugging.

Mas estabilidade sozinha não cria velocidade. O próximo gargalo é: quem pode construir, e com que segurança.

(Se você quer o mergulho técnico profundo nesta camada, veja nosso post de lançamento do MCP Mesh.)

Requisito 2: Um framework comum para construtores
O "SDK para aplicativos de IA corporativa"

Uma vez que o acesso a ferramentas é estável, o próximo desafio é reuso, correção e velocidade segura.

Empresas geralmente não ficam presas porque não conseguem criar capacidades de IA. Elas ficam presas porque essas capacidades são criadas de formas única que não se transferem entre equipes. O que vemos é:

• as equipes reinventam conectores e prompts semelhantes,
• esquemas mudam,
• permissões são adicionadas tardiamente,
• e "qual agente é o real?" se torna um problema social.

Aqui está a mudança que importa: no mundo pré-IA, desenvolvedores principalmente construíam e equipes de negócios principalmente operavam. Em um mundo nativo de IA, usuários de negócios podem cada vez mais construir também.

Isso é poderoso — e arriscado — a menos que você dê à organização um framework compartilhado onde os aplicativos são construídos como ativos duráveis:

• Contratos padrão: esquemas para inputs/outputs, interfaces de ferramentas, hooks de avaliação
• Guardrails por padrão: permissões, limites de dados, regras de redação, logging
• Blocos de construção compostos: conectores aprovados, templates e módulos reutilizáveis
• Um modelo de colaboração: desenvolvedores criam primitivas seguras; usuários de negócios montam workflows dentro de guardrails.

Um framework compartilhado também torna os aplicativos construídos por negócios suportáveis. Quando um workflow atinge um caso extremo, os desenvolvedores não precisam reconstruí-lo — eles podem corrigir e estender o mesmo aplicativo porque usa os mesmos esquemas, modelo de permissões, observabilidade e caminho de deploy. Esse loop é como você obtém autonomia sem acumular uma segunda pilha de automação frágil.

Uma forma prática de fazer isso é suportar duas vias de construção dentro do mesmo framework:

Requisito 3: Distribuição e ciclo de vida
Como o que funciona se torna padrão

Mesmo com um ótimo framework de construção, muitas organizações estagnam no mesmo lugar: as capacidades existem, mas a adoção é acidental. As equipes continuam reconstruindo. Os workflows comprovados não se propagam. A confiança permanece local.

Então você precisa de um sistema interno de distribuição + ciclo de vida que transforme "alguém construiu" em "a organização pode contar com". O ponto aqui é distribuição entre equipes, entre ambientes (dev → prod) e ao longo do tempo (as capacidades evoluem sem que todos reescrevam integrações).

• Descoberta: as pessoas conseguem encontrar o que já existe
• Caminhos de promoção: protótipo → confiado pela equipe → suportado em produção
• Versionamento: atualizações não quebram silenciosamente usuários downstream
• Separação de ambientes: dev → staging → prod é real
• Propriedade operacional: mantenedores, runbooks, regras de descontinuação, visibilidade de incidentes

É também aqui que um modelo similar a loja se torna natural - a UI/UX para ciclo de vida - catálogo, adoção, sinais de governança e atualizações.

E a longo prazo, a distribuição pode se estender para além do reuso interno. Uma vez que as capacidades são empacotadas como aplicativos nativos do MCP com contratos e permissões claras, você obtém um caminho para que construtores de aplicativos publiquem aplicativos MCP pré-construídos — e eventualmente, para que esses construtores monetizem o que criam (internamente através de chargeback/showback, e externamente através de um modelo de marketplace quando fizer sentido).

A escolha arquitetural: consolidação flexível

A maioria das organizações se sente forçada a escolher um de dois extremos:

• O melhor de cada em todos os lugares → máxima flexibilidade, máxima dispersão
• Um consolidador de fornecedor único → mais simples, mas rígido e frequentemente um novo limite de lock-in

A abordagem que achamos que funciona melhor é consolidação flexível:

• consolide a camada de infraestrutura que você não deveria reconstruir (governança, observabilidade, roteamento, controles de custo),
• mantenha as bordas compostas (troque modelos, adote Servidores MCP comunitários, exponha suas próprias APIs internas, construa o que precisa).

É também por isso que convergência de protocolo importa: quando o substrato é padrão, você pode consolidar a governança sem centralizar tudo mais.

O que isso significa para deco

O Sistema de Gerenciamento de Contexto de deco é nossa implementação das três camadas acima: