Décadas de software comercial tornaram rápida a parte estritamente numérica da análise estrutural. Montar uma matriz de rigidez e resolver um sistema linear é um problema bem conhecido e barato do ponto de vista computacional. O tempo do engenheiro vai para outras tarefas: montar o modelo, refazê-lo a cada mudança no projeto de arquitetura, definir carregamentos e combinações, verificar cada elemento segundo a norma e produzir o memorial de cálculo e os desenhos.
O gargalo está nesse trabalho manual em torno do cálculo. É aí, ao montar, alterar, verificar e documentar o modelo, que um agente de IA pode ajudar, com uma condição: não tocar no cálculo.
O que um modelo de linguagem não consegue garantir
Um modelo de linguagem gera texto de forma probabilística. Ele não conhece as leis da física nem o comportamento dos sistemas reais, e pode alucinar: dar respostas que parecem plausíveis e não fazem sentido. Na análise estrutural o risco é concreto, porque modelar exige raciocínio espacial e consistência topológica, e quando o modelo é construído em várias etapas os erros se acumulam.
A restrição mais forte, porém, vem da prática profissional. Todo resultado estrutural leva uma assinatura, com a autoria e a responsabilidade legal que isso implica. O número que dimensiona um pilar é um compromisso do engenheiro habilitado que o assina. Um agente que entrega resultados sem verificação transfere ao profissional o risco de assinar um cálculo que ninguém conferiu.
A correção do resultado tem que ser uma propriedade do solver, não da linguagem.
A fronteira de determinismo
A arquitetura separa o raciocínio em linguagem natural do cálculo numérico. O agente propõe soluções e cenários, mas um resultado só vale se tiver saído de um programa que o agente não pode modificar e que contém a física do problema. O modelo decide qual ferramenta determinística chamar e com quais parâmetros, e trabalha com o que essa ferramenta devolve. Nunca gera um número por conta própria nem inventa geometria.
Na prática, isso se organiza em três camadas. A camada de intenção é o agente: interpreta linguagem natural, faz perguntas de esclarecimento e emite ações tipadas. A camada de cálculo determinístico reúne tudo o que produz dados de engenharia: o solver, os módulos CIRSOC que fazem as verificações e os geradores que expandem uma tipologia em um modelo completo. A camada de documentação produz memoriais, desenhos e quantitativos a partir de resultados já calculados.
O padrão não é novo. Ele predomina na literatura recente sobre agentes de engenharia e aparece em áreas vizinhas: agentes de programação funcionam porque um compilador e uma bateria de testes dizem se o código compila e passa, e o AlphaProof demonstra teoremas porque um verificador formal não deixa passar nenhum erro. Nós o adotamos de forma deliberada como princípio de projeto.
O que a fronteira garante e o que fica de fora
Convém deixar claro o que essa fronteira garante e o que fica fora dela. O que ela garante:
- Toda afirmação numérica do agente pode ser rastreada até um resultado específico do solver: combinação, estação, elemento.
- Toda saída da IA é validada contra o esquema do modelo antes de ser importada, e é recusada se vier malformada ou com campos desconhecidos.
- Se o serviço de IA estiver fora do ar, o solver, o editor e as verificações continuam funcionando.
O que ela não garante: que o modelo idealizado seja o adequado para o problema real (isso é uma decisão de engenharia), que o projeto seja ótimo, que os carregamentos e as hipóteses estejam completos ou que a interpretação da norma dispense revisão.
Um caso que obriga a resolver o modelo de novo
O engenheiro descreve um pórtico de concreto armado com 6 m de vão e 4 m de altura, bases engastadas e uma carga distribuída sobre a viga. O agente pergunta o que falta: aço ou concreto? Bases engastadas ou rotuladas? Há carga lateral? Depois emite a ação que cria o pórtico. O backend a expande de forma determinística em um modelo com 4 nós, 3 elementos e 6 graus de liberdade livres. Adotam-se concreto H-21, viga inicial de 25×40 cm, pilares de 30×30 cm e 30 kN/m sobre a viga.
Com o modelo resolvido, as reações verticais são de 90 kN por pilar e o equilíbrio global é atendido de forma exata: ΣRz = 180 kN = q·L. O momento que governa a viga é Mu = 80,8 kN·m no meio do vão. A verificação à flexão da viga 25×40 com 3Ø16 segundo o CIRSOC 201 dá uma capacidade φMn = 73,3 kN·m. A viga não passa.
| Estado | Seção | Armadura | Mu [kN·m] | φMn [kN·m] | D/C | Verifica |
|---|---|---|---|---|---|---|
| Inicial | 25×40 cm | 3Ø16 | 80,8 | 73,3 | 1,10 | Não |
| Corrigido | 30×55 cm | 3Ø16 | 105,6 | 108,6 | 0,97 | Sim |
Olhe a coluna de Mu. Ao aumentar a viga de 25×40 para 30×55, a demanda sobe de 80,8 para 105,6 kN·m. Num pórtico hiperestático, a estática fixa a soma do momento na extremidade com o momento no meio do vão; a rigidez só muda a forma como essa soma se divide. Uma viga mais rígida em relação aos pilares recebe menos engastamento deles e se aproxima do caso biapoiado, e assim o momento no meio do vão, que é o que governa aqui, aumenta.
Um agente que estimasse o efeito sem recalcular erraria, e soaria igualmente convincente ao fazê-lo.
O exemplo mostra por que é preciso resolver o modelo de novo, além de recalcular a capacidade da nova seção. Numa estrutura hiperestática, aumentar uma seção altera a distribuição dos esforços, e a demanda pode subir justamente no elemento que se queria aliviar.
Tirar um pilar de um projeto já calculado
O segundo caso parte de um pórtico com quatro vãos de 5 m e três pavimentos de 3 m, bases engastadas, vigas de 25×50 cm (4Φ16), pilares de 35×35 cm e 25 kN/m sobre todas as vigas: 20 nós, 27 elementos e 45 graus de liberdade livres. Depois de resolvido e verificado, todas as vigas passam com folga.
Por uma decisão de arquitetura, retira-se um pilar interno do térreo. A ação de edição o remove com validação de integridade estrutural, e o modelo é resolvido de novo; o equilíbrio global se mantém antes e depois (ΣRz = 1500 kN). As vigas que se apoiavam nesse pilar passam a vencer 10 m e, junto com as que estão alinhadas acima delas, redistribuem o apoio perdido. Seis vigas ultrapassam D/C = 1.
| Estado | Seção | Mu [kN·m] | φMn [kN·m] | D/C | Verifica |
|---|---|---|---|---|---|
| Intacto | 25×50 (4Φ16) | 54,2 | 125,3 | 0,43 | Sim |
| Sem o pilar | 25×50 (4Φ16) | 203,9 | 125,3 | 1,63 | Não |
| Redimensionado | 30×65 (5Φ20) | 189,8 | 313,7 | 0,61 | Sim |
O momento da viga governante quase quadruplica. Com 30×65 cm e 5Φ20 nas vigas afetadas e uma nova resolução, todas voltam a passar. O caso mostra também que uma alteração que, feita à mão, exige remodelar, reanalisar, reverificar e redetalhar muitos elementos pode ser resolvida numa conversa curta, com cada número rastreável até o solver e sujeito à aprovação do engenheiro.
Decisões de arquitetura
- Ações tipadas em vez de geração livre de código. Em vários trabalhos anteriores, o modelo escreve scripts em Python que depois são executados contra um solver externo. Aqui, a saída do agente se restringe a um conjunto fechado de chamadas com contratos de entrada e saída explícitos, validadas contra um esquema antes da execução. É uma fronteira mais estreita e mais fácil de auditar do que código arbitrário.
- Um solver próprio, em vez de uma camada sobre um solver de terceiros. O motor foi escrito do zero em Rust, sem dependências externas de álgebra linear, e tem sua própria bateria de verificação contra soluções analíticas e benchmarks de referência: cerca de 6.800 testes passando, além de resultados comparados com um programa comercial nos mesmos modelos, com diferenças abaixo de 0,1 %.
- Conformidade normativa nativa. A verificação segundo o CIRSOC 201 e o 301, que não encontramos implementada de forma nativa em nenhum software de código aberto. O módulo de concreto está implementado e testado; o de aço ainda existe apenas na camada de frontend e não tem uma bateria de testes própria. Dizemos isso para não lhe atribuir uma maturidade que ele não tem.
- Execução no navegador. O motor é compilado para WebAssembly e roda localmente na máquina do usuário, sem servidor de cálculo e sem instalação.
De um solver testado a um solver provado
A fronteira garante que toda afirmação do agente pode ser rastreada até uma saída do solver. Essa garantia herda um limite: o solver é confiável porque está amplamente testado, mas não tem uma prova formal de correção. Uma suíte de testes, por mais completa que seja, só cobre os casos que seus autores imaginaram.
Isso é ainda mais importante neste contexto. Um agente monta modelos, altera-os em várias etapas e lê os resultados para propor novas ações; nesse ciclo, o solver recebe entradas que nenhum engenheiro revisou antes de chegarem ao motor. Se o motor se comportar mal em algum caso-limite (uma matriz de rigidez quase singular, uma geometria degenerada, uma combinação extrema), o agente pode citar esse resultado sem nenhum aviso.
Há duas técnicas para reduzir essa lacuna. O fuzzing baseado em propriedades gera milhares de modelos aleatórios válidos e verifica invariantes que precisam valer para qualquer entrada:
- Equilíbrio global: ΣR = P, independentemente da geometria, dos materiais ou dos apoios.
- Simetria da matriz de rigidez: K = Kᵀ por construção.
- K positiva definida para qualquer estrutura sem mecanismos.
- Invariância a transformações de corpo rígido: transladar ou girar um modelo não muda os esforços internos.
A verificação formal ataca a mesma lacuna pelo outro lado: escrever uma especificação matemática dessas propriedades e demonstrar, com um assistente de provas como o Lean 4, que a implementação a satisfaz. Os testes podem encontrar erros; a verificação formal pode demonstrar que eles não existem dentro do domínio especificado. As duas técnicas se complementam: quando o fuzzer encontra uma entrada que viola uma propriedade, essa propriedade passa a ser candidata a uma prova.
Em que pé isso está hoje
Para fechar, o que já está disponível e o que ainda não está. O solver, o editor, as verificações CIRSOC, o modo educativo e a geração de memoriais e desenhos funcionam hoje no navegador, em stabileo.com, sem instalar nada e sem criar conta. A camada de agentes está em desenvolvimento ativo: suas rotas rodam em ambiente de desenvolvimento e de testes contra um backend próprio, sobre o mesmo solver e os mesmos números que todo o resto, mas esse backend ainda não faz parte do site público.
O ciclo fechado com o solver, em que o agente propõe, resolve, avalia e modifica sem intervenção humana, está no roadmap e não foi implementado. A cobertura normativa nativa se limita ao CIRSOC 201 e 301; o resto é trabalho futuro.
O CAD assumiu a parte mecânica do desenho e a planilha eletrônica, a aritmética repetitiva, e o critério continuou com o engenheiro. O agente é o passo seguinte nessa linha: cuida de montar e alterar o modelo, lançar os carregamentos, rodar as verificações e preparar a documentação. Nada disso transfere a responsabilidade: o número assinado continua sendo do engenheiro.