Décadas de software comercial volvieron rápida la parte estrictamente numérica del análisis estructural. Ensamblar una matriz de rigidez y resolver un sistema lineal es un problema bien conocido y barato de computar. El tiempo del ingeniero se va en otra parte: construir el modelo, rehacerlo cada vez que cambia la arquitectura, definir cargas y combinaciones, verificar elemento por elemento contra la normativa y producir la memoria de cálculo y los planos.
El cuello de botella está en ese trabajo manual alrededor del cálculo. Ahí, en construir, modificar, verificar y documentar el modelo, es donde un agente de IA puede aportar algo, con una condición: que no toque el cálculo.
Lo que un modelo de lenguaje no puede garantizar
Un modelo de lenguaje genera texto de manera probabilística. No conoce las leyes de la física ni el comportamiento de los sistemas reales, y puede alucinar: devolver respuestas que suenan plausibles y son incoherentes. En análisis estructural el riesgo es concreto, porque modelar exige razonamiento espacial y consistencia topológica, y cuando el modelo se arma en varios pasos los errores se acumulan.
La restricción más fuerte, igual, viene de la práctica profesional. Cada resultado estructural lleva una firma, con la autoría y la responsabilidad legal que eso implica. El número que dimensiona una columna es un compromiso del ingeniero matriculado que lo firma. Un agente que entrega resultados sin verificar le traslada al profesional el riesgo de firmar un cálculo que nadie comprobó.
La corrección del resultado tiene que ser una propiedad del solver, no del lenguaje.
La frontera de determinismo
La arquitectura separa el razonamiento en lenguaje natural del cálculo numérico. El agente propone diseños y escenarios, pero un resultado sólo es válido si salió de un programa que el agente no puede modificar y que contiene la física del problema. El modelo decide qué herramienta determinística invocar y con qué parámetros, e integra lo que esa herramienta devuelve. Nunca origina un número ni inventa geometría.
En la práctica, eso se organiza en tres capas. La capa de intención es el agente: interpreta lenguaje natural, hace preguntas de clarificación y emite acciones tipadas. La capa de cómputo determinístico reúne todo lo que produce datos de ingeniería: el solver que resuelve, los módulos CIRSOC que verifican y los generadores que expanden una tipología en un modelo completo. La capa de documentación produce memorias, planos y cómputos a partir de resultados ya calculados.
El patrón no es nuevo. Domina la literatura reciente sobre agentes de ingeniería y aparece en dominios vecinos: los agentes de programación funcionan porque un compilador y una batería de tests dicen si el código compila y pasa, y AlphaProof demuestra teoremas porque un verificador formal no deja pasar un error. Nosotros lo adoptamos a propósito como principio de diseño.
Qué garantiza la frontera y qué queda afuera
Conviene precisar qué garantiza esta frontera y qué queda fuera de ella. Lo que garantiza:
- Toda afirmación numérica del agente es trazable a un resultado específico del solver: combinación, estación, elemento.
- Toda salida de la IA se valida contra el esquema del modelo antes de importarse, y se rechaza si viene malformada o con campos desconocidos.
- Si el servicio de IA no está disponible, el solver, el editor y las verificaciones siguen funcionando.
Lo que no garantiza: que el modelo idealizado sea el adecuado para el problema real (eso es una decisión de ingeniería), que el diseño sea óptimo, que las cargas y los supuestos estén completos ni que la interpretación normativa esté exenta de revisión.
Un caso que obliga a volver a resolver
El ingeniero describe un pórtico de hormigón armado de 6 m de luz y 4 m de altura, con bases empotradas y una carga distribuida sobre la viga. El agente pregunta lo que falta: ¿acero u hormigón?, ¿bases empotradas o articuladas?, ¿hay carga lateral? Después emite la acción que crea el pórtico. El backend la expande de forma determinística en un modelo de 4 nodos, 3 elementos y 6 grados de libertad libres. Se adopta H-21, viga inicial de 25×40 cm, columnas de 30×30 cm y 30 kN/m sobre la viga.
Resuelto el modelo, las reacciones verticales son de 90 kN por columna y el equilibrio global se cumple de forma exacta: ΣRz = 180 kN = q·L. El momento gobernante de la viga es Mu = 80,8 kN·m en el centro de la luz. La verificación CIRSOC 201 a flexión de la viga 25×40 armada con 3Ø16 da una capacidad φMn = 73,3 kN·m. La viga no verifica.
| Estado | Sección | Armadura | Mu [kN·m] | φMn [kN·m] | D/C | Verifica |
|---|---|---|---|---|---|---|
| Inicial | 25×40 cm | 3Ø16 | 80,8 | 73,3 | 1,10 | No |
| Corregido | 30×55 cm | 3Ø16 | 105,6 | 108,6 | 0,97 | Sí |
Mirá la columna de Mu. Al agrandar la viga de 25×40 a 30×55, la demanda sube de 80,8 a 105,6 kN·m. En un pórtico hiperestático la suma del momento de extremo y el del centro del vano está fijada por la estática; lo que cambia con la rigidez es el reparto. Una viga más rígida en relación con sus columnas recibe menos empotramiento de ellas y se acerca al caso biapoyado, así que su momento de centro, que es el que gobierna acá, crece.
Un agente que estimara el efecto sin recalcular se equivocaría, y sonaría igual de convincente al hacerlo.
El ejemplo muestra por qué hay que volver a resolver el modelo, además de recalcular la capacidad de la sección nueva. En una estructura hiperestática, agrandar una sección modifica la distribución de esfuerzos, y la demanda puede subir justo en el elemento que se quería aliviar.
Sacar una columna de un proyecto ya calculado
El segundo caso parte de un pórtico de cuatro vanos de 5 m y tres pisos de 3 m, con bases empotradas, vigas de 25×50 cm (4Φ16), columnas de 35×35 cm y 25 kN/m sobre todas las vigas: 20 nodos, 27 elementos, 45 grados de libertad libres. Resuelto y verificado, todas las vigas cumplen con holgura.
Por una decisión de arquitectura se elimina una columna interior de planta baja. La acción de edición la quita con validación de integridad estructural y el modelo se vuelve a resolver; el equilibrio global se mantiene antes y después (ΣRz = 1500 kN). Las vigas que apoyaban en esa columna pasan a salvar 10 m y, junto con las que quedan alineadas encima, redistribuyen el apoyo perdido. Seis vigas superan D/C = 1.
| Estado | Sección | Mu [kN·m] | φMn [kN·m] | D/C | Verifica |
|---|---|---|---|---|---|
| Intacto | 25×50 (4Φ16) | 54,2 | 125,3 | 0,43 | Sí |
| Sin la columna | 25×50 (4Φ16) | 203,9 | 125,3 | 1,63 | No |
| Redimensionado | 30×65 (5Φ20) | 189,8 | 313,7 | 0,61 | Sí |
El momento de la viga gobernante casi se cuadruplica. Con 30×65 cm y 5Φ20 en las vigas afectadas, y después de volver a resolver, todas verifican. Este caso muestra además que un cambio que a mano exige volver a modelar, analizar, verificar y detallar muchos elementos se resuelve en una conversación corta, con cada número trazable al solver y sujeto a la aprobación del ingeniero.
Decisiones de arquitectura
- Acciones tipadas en lugar de generación libre de código. En varios trabajos previos, el modelo escribe scripts de Python que después se ejecutan contra un solver externo. Acá la salida del agente está restringida a un conjunto cerrado de llamadas con contratos de entrada y salida explícitos, que se validan contra un esquema antes de ejecutarse. Es una frontera más estrecha y más fácil de auditar que el código arbitrario.
- Un solver propio, en lugar de una capa sobre un solver de terceros. El motor está escrito desde cero en Rust, sin dependencias externas de álgebra lineal, y tiene su propia batería de verificación contra soluciones analíticas y benchmarks de referencia: alrededor de 6.800 tests en verde, y resultados contrastados con un programa comercial sobre los mismos modelos, con diferencias por debajo del 0,1 %.
- Cumplimiento normativo nativo. La verificación según CIRSOC 201 y 301, que no encontramos implementada de forma nativa en ningún software de código abierto. El módulo de hormigón está implementado y testeado; el de acero vive todavía sólo en la capa de frontend y no tiene batería de tests dedicada. Lo decimos así para no atribuirle una madurez que no tiene.
- Ejecución en el navegador. El motor compila a WebAssembly y corre localmente en la máquina del usuario, sin servidor de cálculo y sin instalación.
De un solver testeado a un solver probado
La frontera garantiza que toda afirmación del agente es trazable a una salida del solver. Esa garantía hereda un límite: el solver es confiable porque está extensamente testeado, pero no tiene una demostración formal de corrección. Una suite de tests, por exhaustiva que sea, cubre sólo los casos que imaginaron sus autores.
Esto es todavía más importante en este contexto. Un agente construye modelos, los modifica en varios pasos y consulta los resultados para proponer nuevas acciones; en ese ciclo el solver recibe entradas que ningún ingeniero revisó antes de que llegaran al motor. Si el motor se comporta mal en algún caso de borde (una matriz de rigidez casi singular, una geometría degenerada, una combinación extrema), el agente puede citar ese resultado sin advertencia.
Hay dos herramientas para achicar esa brecha. El fuzzing basado en propiedades genera miles de modelos aleatorios válidos y comprueba invariantes que se tienen que cumplir para cualquier entrada:
- Equilibrio global: ΣR = P, con independencia de la geometría, los materiales o los apoyos.
- Simetría de la matriz de rigidez: K = Kᵀ por construcción.
- Definitud positiva de K para cualquier estructura sin mecanismos.
- Invariancia ante transformaciones rígidas: desplazar o rotar un modelo no cambia los esfuerzos internos.
La verificación formal ataca la misma brecha por el otro lado: escribir una especificación matemática de esas propiedades y demostrar, con un asistente de pruebas como Lean 4, que la implementación la satisface. El testing puede encontrar errores; la verificación formal puede demostrar su ausencia dentro del dominio especificado. Las dos técnicas se complementan: cuando el fuzzer encuentra una entrada que viola una propiedad, esa propiedad pasa a ser candidata para una prueba.
Dónde está esto hoy
Para cerrar, qué está disponible y qué no. El solver, el editor, la verificación CIRSOC, el modo educativo y la generación de memorias y planos funcionan hoy en el navegador, en stabileo.com, sin instalar nada y sin cuenta. La capa de agentes está en desarrollo activo: sus rutas corren en desarrollo y prueba contra un backend propio, sobre el mismo solver y los mismos números que todo lo demás, pero ese backend todavía no forma parte del sitio público.
El ciclo cerrado con el solver, en el que el agente propone, resuelve, evalúa y modifica sin intervención humana, está en la hoja de ruta y no está implementado. La cobertura normativa nativa se limita a CIRSOC 201 y 301; el resto es trabajo futuro.
El CAD se hizo cargo de la parte mecánica del dibujo y la planilla de cálculo de la aritmética repetitiva, y el criterio quedó en manos del ingeniero. El agente es el paso siguiente en esa línea: se ocupa de armar y modificar el modelo, cargar las acciones, correr las verificaciones y preparar la documentación. Nada de esto transfiere la responsabilidad: el número firmado sigue siendo del ingeniero.