Contenção É Arquitetura: Deixar a IA Rascunhar uma Mudança no Banco Sem Tocar na Produção

TV
Thiago Victorino
7 min de leitura
Contenção É Arquitetura: Deixar a IA Rascunhar uma Mudança no Banco Sem Tocar na Produção

A linha mais importante do design de referência SchemaFlow, da OpenAI, é uma lista de coisas que o sistema se recusa a fazer. Ele retém a execução de SQL. Deixa migrations por aplicar. Abre zero pull requests. Mantém a produção intocada. O que ele produz é um pacote de artefatos revisáveis, e então para.

Essa recusa é o design inteiro. O SchemaFlow, publicado no OpenAI Cookbook como arquitetura de referência de um parceiro, pega o lugar mais arriscado para colocar uma IA (a camada onde um comando ruim derruba uma tabela ou trava um índice em uso) e mostra como extrair trabalho real de um modelo enquanto a chave segue em mãos humanas. A contenção vive dentro do formato do pipeline, codificada nos próprios estágios em vez de acoplada depois.

Cinco Agentes Estreitos, Não Um Esperto

O instinto com trabalho de banco é pedir o SQL a um modelo capaz e revisar o que volta. O SchemaFlow rejeita esse formato. O cookbook decompõe a tarefa em cinco agentes em estágios, cada um com uma única função e uma saída tipada.

Primeiro, um estágio de parse lê a mudança solicitada e extrai a intenção para uma forma estruturada. Segundo, um estágio de análise de impacto examina o que a mudança toca: objetos dependentes, consumidores a jusante, o raio de explosão. Terceiro, um estágio de plano de execução produz prechecks, postchecks e um caminho de rollback antes de qualquer SQL existir. Quarto, o estágio de geração de SQL escreve os comandos de fato, agora limitado por tudo que os estágios anteriores estabeleceram. Quinto, um estágio de validação determinística confere a saída contra regras independentes do julgamento de um modelo.

A ordem carrega o argumento. O SQL chega em quarto, depois da base estar pronta. Quando o modelo escreve um comando, o impacto já foi mapeado e um rollback já existe. O agente que escreve SQL fica dentro de mudanças cujas consequências um estágio anterior já examinou, porque examinar consequências foi um passo separado e anterior, com sua própria saída.

Um único prompt grande poderia, em teoria, fazer tudo isso. Também colapsaria as fronteiras que tornam o trabalho auditável. Quando um agente faz parse, analisa, planeja, escreve e valida em uma passada só, o raciocínio vira um passo opaco que você fica impedido de inspecionar. Cinco estágios dão cinco pontos de inspeção.

Artefatos Tipados São a Superfície de Controle

Cada estágio emite um artefato estruturado, e a estrutura é imposta. O cookbook usa contratos de schema de saída em Pydantic para que um estágio não consiga entregar ao próximo um bloco de texto livre. A análise de impacto produz um objeto de impacto com campos definidos. O plano de execução produz um objeto de plano com prechecks, postchecks e rollback como elementos de primeira classe. O contrato é o handoff.

Isso importa mais do que parece à primeira vista. Handoffs em texto livre entre passos de IA falham em silêncio. Um estágio produz algo plausível, o estágio seguinte interpreta de forma vaga, e um erro se propaga a jusante vestido de resultado válido. Contratos tipados tornam a falha barulhenta. Quando a análise de impacto falha em produzir um objeto de impacto em conformidade, o pipeline para naquela fronteira e deixa a suposição malformada para trás, bem antes da geração de SQL.

Entre os estágios ficam os portões de validação determinística. São regras, executadas como código puro em vez de chamadas de modelo. Eles pegam a classe de falha silenciosa que checagens probabilísticas deixam passar, os casos em que a saída parece correta para outro modelo mas viola uma restrição rígida. Um revisor humano no fim lê artefatos que já passaram por checagens determinísticas, o que libera a revisão para focar no julgamento enquanto os erros mecânicos que uma regra pegaria já saíram do caminho.

A Fronteira do Rascunho Que Não Executa

A decisão mais difícil e mais valiosa do design é a que limita o próprio poder dele. O SchemaFlow traça uma linha na execução e a sustenta. A saída inteira do modelo é uma proposta. Um humano a aplica, ou a deixa de lado.

Isso inverte a equação de risco habitual para IA em infraestrutura. O perigo com agentes autônomos em sistemas de produção mora além do raciocínio, no momento em que uma ação de aparência plausível, com efeitos no mundo real, roda antes de alguém pegar a falha. Tire a execução do alcance do agente e o pior caso muda de natureza por completo. Uma saída errada do SchemaFlow é um documento ruim, enquanto uma saída errada de um agente autônomo é uma migration ruim já rodando contra a produção.

Fizemos um argumento relacionado em o modelo de permissões do agente como sistema de registro: a segurança se decide pelo que o agente tem permissão de tocar, muito mais do que por quão esperto ele é. O SchemaFlow é esse princípio expresso como arquitetura, específico para a camada de dados. Os agentes são estreitos de propósito, e o estreitamento mais importante está no ponto da ação.

Também muda o que revisão significa. Como o sistema para em um rascunho, o humano revisa uma proposta em repouso em vez de carimbar uma ação já em curso. Ele lê uma análise de impacto, um plano de rollback e um conjunto de comandos, e decide se prossegue. A arquitetura cria as condições para uma decisão de verdade no lugar de uma aprovação reflexa.

Repetibilidade Como Preocupação de Primeira Classe

O cookbook integra o Promptfoo para avaliação, o que ataca um problema que a maior parte do ferramental de IA ignora até doer. Prompts derivam. Modelos são trocados. Um pipeline que funcionava no trimestre passado degrada em silêncio, e a falha fica invisível até uma saída sair errada em produção. Colocar avaliação no design significa que os agentes em estágios podem ser reavaliados sempre que um prompt ou modelo muda, contra um conjunto conhecido de casos.

A mesma disciplina separa sistemas de agentes em produção de demos. Cobrimos o padrão mais amplo em a pilha de operações de agentes: prontidão é algo que você mede em vez de afirmar. O SchemaFlow aplica isso à camada de dados ao tornar o pipeline testável. Os artefatos são tipados, então podem ser verificados por asserção. Os estágios são discretos, então uma regressão se localiza em um estágio. A avaliação faz parte do design central, integrada a como o sistema permanece confiável conforme suas peças mudam.

O Que Esse Padrão Cobre e o Que Deixa em Aberto

Duas ressalvas honestas. O SchemaFlow é autoria de fornecedor, um cookbook de parceiro da OpenAI em vez de um benchmark independente. Leia como arquitetura de referência e um conjunto de escolhas de design que valem adotar, tratando o resultado específico como ainda por provar. O cookbook mostra um padrão. Quanto risco esse padrão remove no seu ambiente fica para você medir.

E o padrão permanece mais estreito que automação completa. O SchemaFlow para bem antes da operação de banco sem mãos. Ele promete que a parte de IA do trabalho termina em um artefato revisável, com um humano sendo dono do ato de execução. Para equipes cujo instinto é perseguir autonomia, isso pode soar como limitação. O estreitamento é exatamente o que torna a IA utilizável em um sistema onde os erros são caros.

A conexão com controle de alucinação é direta. Já escrevemos sobre construir sistemas que contêm alucinações em vez de torcer para os modelos pararem de produzi-las. O SchemaFlow é essa tese aplicada onde mais importa. Ele assume que o modelo às vezes vai errar e arranja a arquitetura para que uma saída errada encontre um portão determinístico ou um revisor humano, mantida longe de um banco em produção.

Faça Isto Agora

Se você deixa, ou planeja deixar, a IA tocar sua camada de dados, copie a fronteira primeiro e a esperteza depois. Decomponha a tarefa em agentes estreitos e em estágios, com saídas tipadas. Coloque análise de impacto e um plano de rollback à frente da geração de SQL. Adicione portões de validação determinística entre estágios para que falhas silenciosas parem numa fronteira e se propaguem por ali adiante. E trace a linha na execução: a IA rascunha, um humano aplica. O mecanismo de segurança vive na arquitetura, bem além da inteligência do seu modelo.


Fontes

A Victorino projeta arquitetura de contenção para IA em sistemas de dados em produção: contato@victorino.com.br | www.victorino.com.br

Todos os artigos do The Thinking Wire são escritos com o auxílio do modelo LLM Opus da Anthropic. Cada publicação passa por pesquisa multi-agente para verificar fatos e identificar contradições, seguida de revisão e aprovação humana antes da publicação. Se você encontrar alguma informação imprecisa ou deseja entrar em contato com o editorial, escreva para editorial@victorino.com.br . Sobre o The Thinking Wire →

Se isso faz sentido, vamos conversar

Ajudamos empresas a implementar IA sem perder o controle.

Agendar uma Conversa