Décadas de software comercial volvieron veloz la parte estrictamente numérica del análisis estructural. Ensamblar una matriz de rigidez y resolver un sistema lineal es un problema bien comprendido y computacionalmente barato. 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 cálculo es la parte rápida. El cuello de botella es el andamiaje manual que lo rodea. Y es exactamente ahí, en el andamiaje, donde un agente de IA puede aportar algo — siempre que no toque el cálculo.
El límite preciso de un modelo de lenguaje
Un modelo de lenguaje genera texto probabilístico. Desconoce las leyes de la física y 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 el modelado exige razonamiento espacial y consistencia topológica, y el modelado multi-paso es propenso a la acumulación de errores.
La restricción, sin embargo, no nace de la ingeniería de software sino de cómo funciona 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 no es un dato más: es un compromiso del ingeniero matriculado que lo suscribe. Un agente que entrega resultados no verificados no aporta valor de ingeniería; 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
En lugar de mejorar el modelo hasta que "calcule bien", se le quita el cálculo. El agente propone diseños y escenarios, pero para que un resultado sea válido tiene que pasar por 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.
La arquitectura separa tres responsabilidades. La capa de intención es el agente: interpreta lenguaje natural, formula 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, 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.
Esta separación no es un hallazgo propio. Es el patrón dominante en la literatura reciente de agentes de ingeniería, y 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; AlphaProof demuestra teoremas porque un verificador formal no deja pasar un error. Lo que se hace acá es adoptarlo deliberadamente como principio de diseño.
Qué garantiza la frontera y qué no
Vale la pena ser preciso, porque una frontera que promete de más es peor que ninguna. La frontera de determinismo garantiza tres cosas:
- 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.
Y no garantiza que el modelo idealizado sea el correcto para el problema real, que es una decisión de ingeniería; ni que el diseño sea óptimo; ni que las cargas y los supuestos estén completos; ni que la interpretación normativa no requiera revisión.
Un caso donde el solver en el bucle no es opcional
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?— y 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 tercera columna de números. Al agrandar la viga de 25×40 a 30×55, la demanda no baja: 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 —el que gobierna acá— crece. Por eso la verificación correcta exige volver a resolver el modelo y no sólo recalcular la capacidad de la sección nueva.
Un agente que estimara el efecto sin recalcular se equivocaría, y sonaría igual de convincente al hacerlo.
Ese es el argumento entero, en un número. No es que el solver sea más rápido: es que la intuición sobre "agrandar la sección mejora la verificación" es falsa en cuanto la estructura es hiperestática, y sólo el solver lo sabe.
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 arquitectónica 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 |
| Re-dimensionado | 30×65 (5Φ20) | 189,8 | 313,7 | 0,61 | Sí |
El momento de la viga gobernante casi se cuadruplica. Adoptando 30×65 cm con 5Φ20 en las vigas afectadas y volviendo a resolver, todas verifican. Lo relevante no es el redimensionado: es que un cambio que manualmente exige re-modelar, re-analizar, re-verificar y re-detallar muchos elementos se resuelve como una conversación corta, con cada número trazable al solver y sujeto a la aprobación del ingeniero.
Cuatro decisiones que sostienen la frontera
- Acciones tipadas en lugar de generación de código libre. Los precedentes hacen que el modelo escriba 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, validadas contra un esquema antes de ejecutarse. Es una frontera más estrecha y más auditable que el código arbitrario.
- Un solver propio, no un envoltorio de terceros. El motor está escrito desde cero en Rust, sin dependencias externas de álgebra lineal, con su propia batería de verificación contra soluciones analíticas y benchmarks de referencia: del orden de 6.800 tests pasando, y resultados contrastados contra 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 ningún software de código abierto implementa de forma nativa. 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, y se dice 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 tiene un límite preciso: el solver es confiable porque está extensivamente testeado, no porque esté probado. Una suite de tests, por exhaustiva que sea, cubre sólo los casos que sus autores imaginaron.
El punto pesa más en este contexto de uso. 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 acortar esa brecha. El fuzzing basado en propiedades genera miles de modelos aleatorios válidos y afirma invariantes que tienen que cumplirse 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 son complementarias: cuando el fuzzer halla una entrada que viola una propiedad, esa propiedad pasa a ser candidata para una prueba.
Dónde está esto hoy
Conviene cerrar con lo que está y lo que 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 bucle solver-en-el-bucle —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 llevó la parte mecánica del dibujo y la planilla de cálculo la de la aritmética repetitiva, sin llevarse el criterio. El agente es el eslabón siguiente: absorbe el andamiaje mecánico y deja el juicio del lado del ingeniero. Ninguna de estas medidas transfiere la responsabilidad. El número firmado sigue siendo del ingeniero.