A Datadog Transformou Governança em Roadmap de Produto

Um lançamento é uma funcionalidade. Dois em uma semana são um roadmap.

Em abril de 2026, a Datadog lançou dois produtos de governança de IA com poucos dias de diferença. O primeiro é um Code Security MCP que se conecta à IDE do desenvolvedor e escaneia o código gerado por IA no momento em que ele aparece — SAST, Software Composition Analysis, detecção de segredos e varredura de Infrastructure-as-Code consolidados atrás de um único servidor MCP local, com autenticação unificada. O segundo é um SAST open-source nativo em IA que usa LLMs no lugar de regras estáticas para reduzir falsos positivos.

Lidos em separado, cada um parece um anúncio de feature. Lidos juntos, na mesma semana, do mesmo fornecedor, outra coisa aparece: uma grande empresa de observabilidade decidiu que governança de código gerado por IA é uma categoria de produto digna de ser disputada — e está correndo para fincar a bandeira na superfície onde o desenvolvedor realmente trabalha.

Essa superfície não é a reunião de auditoria. É a IDE.

O MCP, lido como aposta de produto

O Code Security MCP faz algo muito específico que auditorias trimestrais não fazem. Ele “baixa scanners sob demanda no início de cada sessão”, de modo que as ferramentas rodando contra o seu código estão sempre atualizadas — sem versões fixas, sem ciclos de patch, sem defasagem de tooling de segurança. O desenvolvedor abre a IDE; o MCP traz os scanners mais recentes junto; a sessão roda contra regras que talvez não existissem na terça passada.

O que ele bloqueia é a lista entediante que líderes de governança vêm recitando há uma década — SQL injection e injeções similares, dependências de terceiros vulneráveis, credenciais hardcoded, más configurações de IaC. A novidade não é a categoria. É o local. Esses checks costumavam disparar no commit, no pull request, na pipeline noturna, na auditoria trimestral — ou, na resposta honesta da maioria das empresas, depois de um incidente. Agora disparam dentro do turno em que o agente de IA está escrevendo a linha.

A implicação de governança é estrutural. Se o scanner de segurança mora onde o código está sendo escrito — e se ele se recusa a deixar o padrão vulnerável sobreviver à sessão — então a janela em que um padrão ruim pode se propagar pela base de código encolhe de semanas para segundos. A auditoria não captura depois porque não existe depois. A auditoria acontece na IDE, ou não acontece.

É o mesmo movimento arquitetural que discutimos em a fronteira da governança de publicidade: checks de brand safety migraram da revisão post-hoc de conteúdo para gates pré-flight dentro das próprias plataformas de anúncio. Governança migra para a superfície em que o trabalho é gerado, porque esse é o único lugar em que o custo de um output ruim ainda é barato de corrigir.

O SAST open-source, lido como reivindicação de categoria

O segundo lançamento é fácil de interpretar erroneamente como projeto de pesquisa. Não é. A Datadog abriu o código de uma ferramenta SAST nativa em IA que usa LLMs para avaliar padrões de código e, segundo o próprio blog, alcança “significativamente menos falsos positivos” que os scanners tradicionais baseados em regras.

Falsos positivos são a razão pela qual ferramentas de segurança são ignoradas. Cada alarme falso treina o desenvolvedor a descartar o próximo alerta, e o próximo alerta é o que importava. A indústria de SAST baseado em regras vem brigando com falsos positivos há vinte anos, com engines cada vez mais elaboradas. A aposta da Datadog é que o LLM lê o código como um revisor sênior lê — com contexto — e por isso não tropeça nos padrões que parecem perigosos mas não são.

Se essa promessa se sustenta em condições adversariais é outra conversa. O movimento que importa é lançar isso como open source, na mesma semana do MCP comercial. A versão open-source é o primer da categoria. Ela planta a ideia — IA deve escanear IA — na cabeça de todo engenheiro de segurança que abre o repositório, e faz isso sob o nome da Datadog. Dentro de seis meses, quando esses mesmos engenheiros forem escolher uma solução paga, o formato do problema já vai parecer com o formato da Datadog.

É assim que categorias de produto são construídas. Não com um lançamento, mas com uma versão gratuita e uma versão paga lançadas perto o suficiente para que o mercado as leia como uma tese única.

Governança como superfície de produto

A tese é: governança não é mais função de auditoria. É superfície de produto, e a superfície é a IDE.

Já defendemos isso em outros domínios — agentes de marketing precisam de governança em runtime, não de PDFs de política; brand safety em publicidade migrando para dentro das próprias plataformas de anúncio. Os lançamentos de abril da Datadog são a mesma tese no domínio de segurança: checks de governança que moravam em tickets, dashboards e revisões trimestrais estão sendo puxados para o turno em que o trabalho acontece. A ferramenta que para uma SQL injection no commit é uma ferramenta de governança. A ferramenta que para a mesma injeção enquanto o desenvolvedor ainda está digitando é uma feature de produto.

As duas não são a mesma coisa, mesmo pegando o mesmo bug. A ferramenta de governança vive em outra área, roda em outra cadência e sai de outro orçamento. A feature de produto vive na IDE, roda em toda sessão, e é paga pelo time de plataforma que entrega para os desenvolvedores. A Datadog está apostando que o segundo é o mercado maior, e que o primeiro é um resíduo encolhendo que vai acabar absorvido.

Se a aposta está certa — e dois lançamentos em uma semana é um sinal de que a Datadog acredita nela com força — então a pergunta para líderes de plataforma não é mais “temos um programa de governança”. É: onde na nossa stack a governança vira superfície de produto, e quem é dono do roadmap? Se a resposta ainda é “o time de segurança abre um ticket”, a resposta está obsoleta. Se a resposta é “a IDE se recusa a deixar passar”, ainda há trabalho sobre quem constrói essa recusa e como ela é paga.

A leitura em uma frase

Governança não está indo para a nuvem. Está indo para o cursor.

Os lançamentos da Datadog importam porque tornam esse movimento visível em um domínio — segurança de aplicação — que passou vinte anos tentando fazer o oposto, empurrando checks cada vez mais para jusante para que o desenvolvedor não precisasse pensar neles. A nova direção é inversa. Empurre o check o mais perto possível do momento em que o código é escrito. Faça dele um produto. Dê a ele um roadmap. Lance dois na mesma semana para que o mercado entenda que não é uma feature.

Times que ainda tratam governança de IA como artefato de compliance — um PDF, uma revisão trimestral, um módulo de treinamento — não estão errados sobre o risco. Estão errados sobre o lugar. O lugar é a IDE, e os fornecedores que entregam na IDE vão ser donos da história de governança quer os times de governança concordem ou não.

A resposta certa não é competir com a Datadog em features de scanner. É perguntar, para toda superfície adjacente a IA na sua própria stack, uma pergunta única: onde o check de governança pertence, e ele está perto o suficiente do momento de geração para que um output ruim nunca tenha chance de se propagar? Se essa distância é medida em horas ou dias, o modelo MCP já te ultrapassou. Se é medida em turnos, você está na nova categoria.

Fontes

• Datadog. “Introducing the Datadog Code Security MCP.” Abril de 2026. https://www.datadoghq.com/blog/introducing-datadog-code-security-mcp/
• Datadog. “Introducing Our Open Source AI-Native SAST.” Abril de 2026. https://www.datadoghq.com/blog/open-source-ai-sast/

Ajudamos times de plataforma a transformar governança de overhead de auditoria em superfície de produto: contato@victorino.com.br | www.victorino.com.br