O desenvolvimento de IA virou um loop fechado: o CoreWeave Forge transforma a produção na próxima versão

Na maioria das empresas, quem constrói um sistema de IA e quem o acompanha em produção usam ferramentas diferentes, dados diferentes e, muitas vezes, estão em times diferentes. A engenharia treina ou configura num lugar. A operação olha dashboards em outro. Quando algo dá errado, alguém exporta uma amostra de casos ruins para uma planilha, manda por e-mail, e algumas semanas depois sai uma versão nova. O loop existe, mas passa pela caixa de entrada das pessoas.

O lançamento do Forge pela CoreWeave em 30 de setembro, seguido um dia depois pelos CoreWeave Notebooks, é uma aposta de que esse loop deveria ser produto. Não é a única aposta do tipo, e ninguém precisa da CoreWeave para agir a partir dela. Mas ela descreve com clareza para onde as plataformas de IA estão indo.

O que a CoreWeave lançou

A CoreWeave descreve o Forge como uma camada de desenvolvimento que reúne, numa plataforma conectada, a construção de modelos e de agentes ao longo de todo o ciclo, aberta a modelos, frameworks e outras nuvens. O loop declarado é: rodar, observar, curar, melhorar, avaliar e repetir.

Entre as peças listadas pela empresa estão o Weights & Biases Models para acompanhar experimentos; o Agent Lens, para observabilidade de agentes em produção; os Sandboxes, já com disponibilidade geral, ambientes isolados para uso de ferramentas por agentes, aprendizado por reforço e avaliação; um Registry com versões de checkpoints de modelos e configurações de agentes; o Post-Training, com aprendizado por reforço serverless, fine-tuning supervisionado e destilação; Inference com um recurso de RL Rollouts em preview; e o ARIA, agente de código já em disponibilidade geral que analisa dados de experimentos e de observabilidade. A CoreWeave cita MasterClass e Canva como primeiros usuários. O Forge tem edições Free, Pro e Enterprise. A empresa também divulga números de desempenho e custo para alguns componentes; não vimos medições independentes e não os repetimos aqui.

O texto de 1º de outubro sobre os Notebooks, assinado por Julia Rose e Akshay Agrawal, traz notebooks Python reativos baseados no projeto open source marimo. Eles abrem dentro de um projeto já ligado aos seus experimentos, artefatos e resultados de avaliação, e aceitam Python e SQL. O que aparece como trabalho futuro, e não lançado: publicar visões do notebook como painéis permanentes no Workspace, hospedar notebooks como aplicações de dados, mais capacidade de computação no sandbox e o ARIA escrevendo células a partir de uma descrição.

1. Rodar em produção
2. Observar traces e falhas
3. Curar casos em datasets
4. Melhorar: prompt, configuração ou treino
5. Avaliar contra uma régua fixa
6. Liberar uma mudança versionada

Onde os controles da empresa se encaixam

O que muda quando o loop fecha

A história de verdade não é “mais um notebook”. É a distância cada vez menor entre uma falha em produção e a próxima versão do sistema. Isso é bom para a qualidade. E também muda três controles de lugar.

Dado de produção vira dado de desenvolvimento. Traces carregam prompts reais, documentos recuperados e respostas. Quando passam a alimentar curadoria e treino, a pergunta deixa de ser só quem pode vê-los e passa a ser se eles podem ser usados para mudar o sistema. Aqui a LGPD é direta: o princípio da finalidade exige que o tratamento siga os propósitos informados ao titular. A conversa de um cliente com o atendimento foi coletada para atendê-lo; usá-la para treinar o próximo modelo é outra finalidade, que precisa de base legal, de aviso de privacidade compatível ou de anonimização feita de verdade. Decida isso antes de construir o encanamento, não depois.

Cada iteração é uma mudança. Um checkpoint com fine-tuning ou uma configuração nova de agente é uma mudança num sistema em produção. Em bancos e seguradoras, alterações de modelo já passam por governança de risco de modelo e por comitês de mudança. Um loop mais rápido não elimina a validação. Significa que a validação precisa ser tão automatizada e versionada quanto o próprio loop.

A avaliação vira portão, não relatório. Num loop fechado, a etapa de avaliação decide o que vai para produção. Isso só funciona com um conjunto de avaliação fixo, limites acordados e alguém responsável por eles. Defendemos esse ponto quando o AIP Evolve da Palantir passou a deixar agentes proporem mudanças em sistemas de IA: a avaliação é a superfície de controle. O desenho do Forge coloca a mesma ideia no centro da plataforma.

Plataforma ou montagem?

Muitas empresas já montaram partes desse loop: uma ferramenta de observabilidade, um rastreador de experimentos, um framework de avaliação, um registro de modelos, em geral na nuvem principal. No ecossistema Microsoft, é comum ter avaliação e tracing no Azure AI Foundry ao lado do Azure Machine Learning. A questão não é comprar ou não o Forge, e sim se as suas peças estão de fato ligadas. Uma pessoa da engenharia consegue ir de um trace com falha em produção ao conjunto de avaliação e à próxima versão sem exportar um arquivo?

Se a resposta honesta for não, a lacuna é o loop, não uma ferramenta específica. Como dissemos no nosso texto sobre observabilidade de agentes, monitoramento que não alimenta melhoria é só metade do trabalho.

O que fazer agora

1. Acompanhe uma falha real de ponta a ponta. Meça quanto tempo leva de uma resposta ruim em produção até a correção em produção, e conte as passagens manuais.
2. Escreva uma regra de uso de dados para traces: quais fontes podem virar conjunto de avaliação, quais podem virar dado de treino, com que anonimização, e com o DPO assinando junto.
3. Congele um conjunto de avaliação por caso de uso, versione e faça da aprovação nele uma condição de liberação.
4. Versione tudo o que muda comportamento: prompts, configurações, checkpoints e definições de ferramentas, num registro só.
5. Separe o que foi lançado do que é promessa ao avaliar qualquer plataforma, inclusive esta.

Em resumo

Sistemas de IA melhoram mais rápido quando a evidência de produção volta direto para o desenvolvimento. A CoreWeave está empacotando esse loop; outros virão, e alguns times vão continuar montando o seu. Seja qual for a ferramenta, um loop fechado precisa de três coisas para ser seguro: regras sobre o que o dado de produção pode ensinar ao sistema, um portão de avaliação com dono e versões que alguém consiga desfazer.