Every few weeks, someone tells me that AI is about to replace finite element analysis. The claim usually arrives with a striking demo: a neural network that predicts a stress field in milliseconds, or an assistant that builds a model from a sentence. The demos are impressive. The conclusion drawn from them is usually wrong.
Over the past months I have spent a lot of time thinking about AI and machine learning in engineering simulation, and comparing notes with practitioners who are deploying these methods in real projects. What struck me most is how consistent the lessons are. People working on very different problems, in different industries, with different tools, keep arriving at the same conclusion.
The bottleneck is not the AI method. It is data quality, a clearly defined validity domain, validation that reflects the actual decision, and traceability. And through all of it, the engineer keeps responsibility for the decision.
If you have followed this newsletter for a while, that will sound familiar. It is the same message I repeat about FEA itself: the software is not the hard part. Understanding what you are modeling, why, and how you will know if the answer is right is the hard part. AI does not change that. It raises the stakes.
In this article I want to share the questions I believe matter most, the difficulties that keep coming up, the things that turned out differently than expected, how to decide whether an AI model is reliable enough to use, and what I expect the next twelve months to look like.
Four different problems hiding under one label
The first source of confusion is vocabulary. “AI in simulation” is used to describe at least four distinct activities, and they have very little in common in terms of limits, cost and risk.
Replacing the solver. A learned model predicts the response directly, without solving the governing equations. This is the most ambitious use and the one that attracts the most attention.
Accelerating the solver or the process. Surrogate models, reduced order models (ROMs), physics-informed machine learning and design-space exploration. Here AI sits next to the physics-based solver and helps us evaluate many more designs than we could afford otherwise.
Generating models with generative AI. Producing geometry, meshes, input decks or load cases from a description or from previous examples.
Orchestrating workflows. Using AI, increasingly in the form of agents, to run, chain and supervise the steps of an existing simulation process: setup, execution, post-processing and reporting.
When these are lumped together, every conversation becomes muddled. Someone worried about a surrogate extrapolating outside its training range is talking past someone excited about an agent that writes reports. Both are legitimate topics. They are not the same topic.
So the first question I ask in any AI discussion is simple: where in the chain does this belong, and what exactly is it supposed to do? The answer determines what data you need, what can go wrong, and what evidence you will need before anyone uses the result.
My own position is clear. In engineering, AI is a complement to physics-based simulation, not a replacement for it. Deterministic methods remain the validation reference. That is not nostalgia. It is a consequence of how engineering decisions are justified, which brings me to trust.
Trust, traceability and the question of evidence
An engineer must be able to explain how a result was reached. In practice that means tracing it back to the model, the assumptions, the inputs, and, for an AI model, the training data and the validation process. In regulated industries such as aerospace, this is not optional. A result must be justifiable to a certification authority. “The network said so” is not a justification.
This leads to the question I consider the most important of all: what evidence is required before a prediction is allowed to drive a design decision?
That evidence has at least three components:
The validity domain. Over what range of geometry, materials, loads and boundary conditions has the model been shown to work?
Behavior outside the training domain. What happens when the input moves beyond what the model has seen, and how will we know that it has?
Quantified uncertainty. How confident is the model in this particular prediction, not on average, but here?
The third point deserves emphasis. A model that is good on average can still be wrong exactly where the part fails. Structural failure is a local phenomenon. It happens at a fillet, a fastener hole, a ply drop, a weld toe. A global accuracy score says almost nothing about whether the model captures the peak stress in the one region that governs the design.
There is also an organizational side to trust. As soon as AI agents start to execute steps of a workflow on their own, the question is no longer only technical. Who validates what, at which step, and with what human oversight? Those questions need answers before the agent is switched on, not after the first surprising result. And the protection of sensitive engineering data must be part of the same conversation, because training data and model inputs are often the most valuable intellectual property a company has.
The data problem nobody budgets for
If there is one difficulty that every practitioner mentions, it is data. In many fields, machine learning benefits from abundant, cheap data. Simulation is the opposite.
Each data point is an expensive simulation. Generating a training set for a surrogate means running a design of experiments, often with high-fidelity models, on real compute resources. The data is high-dimensional (full fields over complex geometries) and often underdetermined: far fewer samples than the number of parameters you would like to learn.
Existing data is rarely usable as it is. Most companies have years of simulation results on disk. In theory this is a gold mine. In practice it is fragmented, inconsistent, poorly labeled and poorly documented. Models were built with different conventions, different mesh densities, different material cards, and often nobody wrote down which run was the final one. Before it can train anything, this data needs significant cleaning and enrichment.
The data must cover the right conditions. A training set that does not include the operating conditions you care about cannot teach the model about them, no matter how large it is.
These constraints force a different approach from the one used in mainstream machine learning. Data-efficient methods become essential: adaptive design of experiments, multi-fidelity models that combine many cheap runs with a few expensive ones, and active learning that chooses the next simulation where it adds the most information.
They also force an uncomfortable economic question. If producing high-fidelity training data costs hundreds of solver runs, is the surrogate worth it? Sometimes the answer is clearly yes: a design optimization loop that needs tens of thousands of evaluations, or a real-time application. Sometimes the honest answer is that running the solver directly would have been cheaper.
A related point surprised me less than it surprised some data scientists: models trained on company-specific, well-labeled data are often more valuable than models trained on large generic datasets. A company that knows its products, its load cases and its failure modes, and has organized its data accordingly, holds an advantage that no general model can easily replicate.
Process discipline comes first
Before any AI work starts, the simulation process itself must be consistent and repeatable. This sounds obvious. It is routinely ignored.
Tool default settings are tuned for other problems than yours. Run-to-run variability, from meshing, contact, solver tolerances or even the order in which operations are performed, can be large enough to mislead a learning algorithm. If two “identical” runs give different answers, the model will learn noise and present it as physics.
This is where the fundamentals of FEA meet the fundamentals of machine learning. Clean training data starts with verified simulations: converged meshes, checked boundary conditions, sensible material models, and documented assumptions. If the source simulations are wrong, the AI model will reproduce the error faithfully, and much faster.
Integration matters just as much. Real pipelines mix CAD, multiphysics solvers, PLM or SPDM (simulation process and data management) systems and HPC resources. An AI model that cannot be called from the orchestrator that runs the rest of the process will remain a demo. In several projects, the integration effort turned out to matter as much as the choice of algorithm.
Choosing the battles: value and scope
The hardest decision in an AI project is often made before any code is written. When is AI worth applying at all? How narrow should the scope be? How will we measure value against the effort of implementing and, just as important, maintaining the model?
Failed pilots are now common. In most cases I have seen, the failure was not caused by a weak algorithm. It was caused by a poorly chosen use case: too broad, too vague, with no clear decision attached to it, or with no realistic path from a proof of concept into the production workflow. Use case identification and qualification is a skill in its own right, and it deserves as much attention as model architecture.
A good AI use case in simulation usually has a few things in common. It is recurring, so the investment in data and validation pays back many times. It is bounded, so the validity domain can be defined and checked. It supports a decision whose consequences are understood. And it has a physics-based reference available to verify the result when it matters.
All of this happens under growing governance and regulatory pressure on software that embeds AI. There are no widely accepted standards yet for testing and approving AI models in engineering. Each company sets its own rules, which slows adoption and makes it difficult to compare approaches. A controlled, traceable environment, typically built around an SPDM system, is becoming a prerequisite rather than a luxury.
What turned out differently than expected
This is the part of the discussion I find most valuable, because it is where experience contradicts expectation.
The algorithm was not the hard or decisive part. Data generation, the definition of the parameter space, validation, and the way the work was set up and checked dominated the effort. In one case, a single setting change produced a more than tenfold improvement. Not a new architecture. Not more data. One setting. Anyone who has spent years debugging FE models will recognize the pattern: the details of the setup decide the outcome.
The value came from the lifecycle around the model. Retraining, monitoring of the validity domain, integration into optimization loops and monitoring of drift mattered more than the sophistication of the model itself. The best results came from industrializing the lifecycle, not from running a separate data science project on the side.
A less accurate model can be more useful. A model that is slightly less accurate but robust, efficient and easy to integrate often delivers more value than a more accurate one that is fragile or difficult to deploy. Engineers have always made this trade-off with idealized models. A beam model that runs in seconds and that everyone understands is often more useful than a detailed solid model that nobody fully trusts.
Good test metrics did not guarantee reliability. Two examples illustrate this well.
A surrogate degraded silently on a new design that was inside its training window. The cause was a physical discontinuity, a change in behavior that the training data did not resolve. Nothing in the global metrics warned anyone.
Some training runs produced convincing results while having learned nothing at all. The model was predicting little more than the mean of the training data, and on a well-behaved test set that can look surprisingly respectable.
Both cases carry the same lesson: a test score is a statement about a test set, not about the physics.
Insights emerged before any model was trained. Simply structuring the data for machine learning exposed missing information and dependencies that nobody had noticed. This is an underrated benefit. The discipline required to prepare data for AI improves the simulation process itself, even if the AI model is never deployed.
Adoption was faster than expected once engineers saw turnaround times drop while confidence in the results was maintained. Engineers are not resistant to new tools. They are resistant to tools they cannot trust. Show them both speed and evidence, and they adopt quickly.
Project durations varied enormously. Technically similar projects took anywhere from a few weeks to several years. Estimating the size and risk of an AI project upfront is a skill in itself, and most organizations do not have it yet.
Post-processing became a bottleneck. AI-enabled workflows produce large volumes of results. There is a clear need for post-processing tools that can handle that volume and track how solutions evolve across designs, iterations and model versions.
How to decide whether an AI model is reliable enough
This is the question I am asked most often, and my answer always starts the same way: reliability is specific to a task and a domain. It is never universal, and it is never a single score.
Start from the intended use
What decision does the model support? What accuracy does that decision require? What are the consequences of an error?
Criticality sets the evidence bar. A surrogate used for early design exploration, where it ranks concepts and the best ones are analyzed in detail afterward, needs far less evidence than a model used in final sizing. And for final sizing, my position is firm: the result should always be re-verified with high-fidelity analysis before sign-off.
Measure what the decision depends on
Global averages and Root Mean Square Error are convenient, but they rarely reflect the decision. Use metrics tied to the quantity that matters: the local error in critical regions, the peak stress at the hot spot, the margin of safety, the first natural frequency, the buckling load. Application criteria such as speed, interpretability by a domain specialist, or field-specific acceptance criteria can matter more than generic AI metrics.
Validate independently and look for trouble
Validate against data the model has never seen: high-fidelity simulations, physical tests, and analytical references where they exist. Do not stop at a random test split. Deliberately probe the boundary cases, the extreme designs and the sparsely sampled regions of the design space. That is where models fail, and that is often where designs fail too.
Define the validity domain explicitly
Document the training envelope in metadata, alongside the validation results, so that anyone using the model knows where it has been shown to work. Then go one step further: detect out-of-distribution inputs automatically, for example by quantifying how similar a new input is to the training data, and warn the user when a prediction falls outside the envelope.
Attach uncertainty to every prediction
A prediction without an uncertainty estimate is incomplete. Confidence intervals, ideally visualized directly on the geometry, show the engineer where the model is sure and where it is guessing. The model should also be able to say, in effect: “for this case, run the full simulation instead.”
Check physical plausibility
Does the predicted field satisfy equilibrium in a rough sense? Are the reactions consistent with the applied loads? Does the deformed shape make sense? Are the trends with respect to thickness, stiffness or load magnitude in the right direction? These are the same sanity checks I teach for FE models, and they apply just as well to AI predictions.
Verify the training data itself
The source simulations must be verified. A surrogate trained on unconverged meshes or wrong boundary conditions will learn those errors with great confidence. Data quality and data provenance are part of model reliability, not a separate topic.
Repeat before believing
Several early conclusions did not survive a rerun. Repeat the training, change the random seed, change the sampling. If the conclusion changes, it was not a conclusion.
Treat reliability as continuous
Reliability is not a box ticked once. Track model versions. Compare periodically against the reference solver to catch drift as designs evolve. Retrain in a controlled and recorded way. Again, SPDM is the natural enabler.
Trust will build through use, exactly as it did when simulation started to replace physical tests. Nobody trusted FEA blindly in the beginning. Trust was earned through correlation, documentation and accumulated experience. AI models will follow the same path, and there is no shortcut.
Borrow from software engineering
Finally, apply the practices that software engineering developed for exactly this kind of problem: unit tests, integration tests and quality assurance applied to engineering workflows. A simulation pipeline with an AI component is software. It should be tested like software.
V&V has to grow up
Everything above points to one conclusion: verification and validation must be extended to cover AI and machine learning models.
Our V&V frameworks were built for deterministic, physics-based models. We verify that the equations are solved correctly and validate that the right equations were chosen, against tests and reference solutions. An AI model adds new layers to that chain: the training data, the sampling strategy, the architecture, the training process, the validity domain and the uncertainty estimate. Each of these needs its own verification step and its own documentation.
The good news is that the mindset does not change. V&V has always been about answering one question honestly: how do I know this result is good enough for the decision I am about to make? AI does not change the question. It adds new ways for the answer to be wrong.
Agents, autonomy and who signs the drawing
Agentic AI deserves its own discussion, because it shifts the problem from technical to organizational.
An agent that can set up a model, launch a run, extract results and draft a report is useful. It removes a large amount of repetitive work. But every step it performs is a step that was previously checked by a person, sometimes informally, sometimes without anyone noticing that the check was happening. An experienced analyst glancing at a deformed shape before moving on is performing verification. If the agent skips that glance, who performs it?
Before deploying agents, organizations need clear answers to a few questions:
Which steps can the agent perform autonomously, and which require human review?
At which points must a person approve before the workflow continues?
How is every action recorded, so that the result remains traceable?
Who is accountable when the agent produces a plausible but wrong result?
The last question has only one acceptable answer. The decision must remain the engineer’s. The agent can prepare, execute and summarize. The engineer understands, judges and signs.
What I expect over the next twelve months
Predictions in this field age quickly, so I will keep these grounded in what is already visible.
Agentic workflows will move into production. Agents will run existing workflows, help build new ones, and act within them across setup, execution, post-processing and reporting. The engineer’s role will shift from execution toward supervision. Mature organizations with highly automated simulation processes will adopt this first, for recurring tasks. The Model Context Protocol (MCP) may well become a standard interface between agents and engineering tools.
There is a dissenting view that deserves to be heard: experienced engineers will still make many design decisions faster, and with fewer resources, than any agent-driven workflow. I think this is right for a large class of problems. Experience compresses analysis. A senior analyst often knows which load case governs before the first run. That knowledge is exactly what agents do not have, and what we should be careful not to lose.
Hybrid physics and data approaches will become the norm. Surrogates and ROMs will be used for exploration, with high-fidelity simulation kept for verification and certification. Use of multi-fidelity models, domain-specific foundation models and geometric deep learning will grow, along with automated sampling and active learning.
Progress will come more from evaluation than from models. Expect more emphasis on uncertainty quantification and out-of-domain detection. Today, capability is running ahead of our ability to demonstrate trust. Closing that gap, not building bigger models, will set the pace of adoption.
Standards, benchmarks and regulation will gain weight. Demand for transparency, traceability and cybersecurity of AI components will grow, and with it the pressure for shared benchmarks and accepted approval processes.
Data management will become the differentiator. Automated lineage tracking and a digital thread from design to decision will matter more and more. The companies that advance fastest will not be those with the most advanced models. They will be those with the best-organized data.
Access will broaden. Natural-language interfaces will open expert workflows to non-experts, with AI assistants embedded in simulation tools and semantic search across models, results and documentation. This is a real opportunity and a real risk. Making a workflow easier to run does not make its results easier to interpret. If anything, it increases the need for fundamentals, because more people will be producing results they did not build themselves.
The market will consolidate. Established CAE vendors with in-house AI will compete against solver-agnostic platforms, and interoperability will come under pressure.
And most change will be incremental. No single breakthrough will transform the field in a year. The steady gains will come from AI literacy, better data management and more efficient models as compute demand keeps growing.
The engineer is still the one who decides
When I look across all of these questions, one message stands out. The bottleneck is not the AI method. It is data quality, a defined validity domain, validation that reflects the decision, and traceability. And the engineer keeps responsibility for the decision.
None of this is an argument against AI. I am convinced that AI will make simulation faster, broader and more accessible, and that it will let us explore design spaces we could never afford to explore before. But it will do so only for organizations and engineers who bring the same discipline to AI that good analysts have always brought to FEA: understand the physics, question the inputs, verify the process, validate against reality, and never confuse a convincing picture with a correct answer.
For engineers, the practical message is reassuring. The skills that make a good analyst today, such as judgment, sanity checking, understanding of boundary conditions and load paths, and the habit of asking “how do I know this is right?”, are precisely the skills that AI workflows need most. Fundamentals are not becoming obsolete. They are becoming the control system.
I would like to hear from you. If you have deployed AI or machine learning in your simulation work, what surprised you? What evidence did you need before you trusted a prediction? And who, in your organization, signs the decision when an AI model is in the loop?