When AI recommendations become engineering decisions

Successful organizations provide the context needed to make AI recommendations explainable, traceable, and trustworthy.


This article was written and contributed to Engineering.com by Rob McAveney, CTO, Aras. All opinions are his own.


In recent conversations with engineering leaders, I’ve noticed an increasing divide. Some organizations are taking an intentional approach to AI adoption, while others are waiting for technology vendors to define the path forward. The organizations making the most progress aren’t waiting. They are learning by doing while the technology continues to evolve.

We are already seeing this as AI agents move into day-to-day engineering workflows. AI agents give engineering teams a practical way to manage the growing volumes of connected product information. They help teams understand relationships and implications that otherwise would take significant time to uncover. As those insights begin to inform engineering recommendations, there’s a new question on the table: what happens when AI’s recommendations become part of the engineering process?

Once an AI recommendation begins influencing engineering decisions, it’s now subject to the same expectations as any other engineering input. Teams need to understand what information the AI evaluated, how conclusions were reached, and if the recommendation reflects the full context of the product.

In my experience, the biggest differentiator isn’t the AI model itself. It’s the quality, connectivity, and traceability of the engineering data behind it. As AI agents become part of engineering workflows, their recommendations need to be validated and traced back to the data that produced them.

The organizations that will get the most value from AI won’t necessarily have the most sophisticated models. They will be the ones that provide the context needed to make recommendations explainable, traceable, and trustworthy.

From faster output to better decisions

Engineering has always been about translating intent into something that works in the real world. Requirements become designs, designs become products, and those products move through manufacturing, testing, deployment, and long-term support. When something changes, its impact and consequences affect the entire lifecycle.

One thing I’ve noticed in customer conversations is that many organizations still think about AI as a way to automate individual engineering tasks. I believe the biggest gains come from redesigning engineering workflows rather than simply optimizing isolated steps.

AI agents help by processing connected engineering data at a scale that isn’t practical manually. As products become more software-driven and multidisciplinary, engineers need to understand relationships that span requirements, software, manufacturing, suppliers and compliance. AI helps teams manage that growing complexity while keeping engineers focused on the decisions that require human judgment.

The real challenge begins when those recommendations start influencing decisions that extend beyond the immediate task. Even slight changes can affect firmware behavior, calibration, test coverage or compliance once they move further downstream.

It is easy to generate something that looks correct. It is much harder to make sure it behaves correctly once it moves through validation, manufacturing and service.

Early areas of value for AI agents  

Let’s look at how requirements management can benefit from AI agents. Many engineering teams are still working with requirements documents that span hundreds or even thousands of individual requirements. Ideally, we want to turn that information into something that can be traced and managed across the lifecycle, but doing so requires significant effort.

AI agents can help by interpreting the document, identifying requirements, tables, and supporting content. It can then convert that information into structured data that can be connected to the broader engineering environment. Instead of remaining trapped inside a document, the information can connect to downstream activities.

In this scenario, the agent performs the heavy lifting of organizing and enriching the information. Engineers remain responsible for validating the results, applying judgment, and determining what actions should follow.

Bill of material structures present a similar challenge. Modern products can contain thousands of interconnected components spanning mechanical, electrical, electronic, and software domains. Engineers can see the data but understanding how changes propagate across those relationships is the harder problem.

When something changes, it can have consequences that extend well beyond the engineering team. Evaluating those downstream impacts manually becomes increasingly difficult as products grow more complex.

AI agents can analyze those connected relationships, identify patterns, and surface potential impacts far earlier than would be practical through manual review alone. That visibility helps engineering teams focus attention where it matters most while preserving human oversight and decision-making.

In both examples, the division of responsibility stays the same. Agents help organize and connect engineering data while surfacing potential impacts. Engineers remain responsible for validating recommendations and making decisions.

Engineering data is the real constraint

In conversations with manufacturers, much of the discussion around engineering AI focuses on model capabilities. For many organizations, the bigger constraint is the data environment those models operate within.

Product information is distributed across PLM systems, CAD tools, requirements repositories, ERP platforms, manufacturing systems, quality applications, supplier environments, and countless spreadsheets, documents, and emails accumulated over time. Engineers learn how to navigate these environments because they understand the context behind the data. They know which systems to trust, where the exceptions are, and how decisions are made.

AI agents depend on that same context. They rely on accurate relationships between requirements, product structures, changes, test results, and downstream activities. When those connections are incomplete or inconsistent, recommendations become less reliable.

An agent may reference an outdated revision, overlook a dependency, miss a supplier constraint, or assume a validation activity has been completed when it has not. The recommendation may appear reasonable. Engineering decisions rarely exist in isolation, and even small gaps in context can create downstream consequences.

Many engineering organizations worry about introducing AI into decades of accumulated systems, processes, and unstructured product data. At the same time, I’m seeing others use AI to turn unstructured engineering information into structured, connected data that becomes far more useful across the engineering lifecycle.

Connected product information provides the foundation for that understanding. When you have a digital thread that connects requirements, product structures, changes, test results, and downstream activities, decisions and dependencies can be evaluated in context rather than in isolation. Without that context, organizations risk making decisions based on incomplete information, even when the recommendation itself appears reasonable.

Trust is built, not assumed

As AI agents move from analysis toward recommendation and action, trust is vital. Engineering organizations already operate within environments that demand accountability, traceability, compliance, and validation. Those expectations do not change simply because AI becomes part of the process.

If an agent recommends changing a requirement, modifying a product structure, escalating a quality issue, or prioritizing a corrective action, engineers need to understand what information was evaluated and how the recommendation was developed.

As things evolve, I believe governance will extend beyond data itself. Organizations will need to decide which AI models and agents are appropriate for different engineering tasks while ensuring they’re working from trusted engineering data.

Governance, observability, and explainability provide the foundation for that understanding.

  • Governance establishes clear operating boundaries. It determines what data agents can access, what actions they can take, and how authority is delegated.
  • Observability provides visibility into system behavior. Teams need to understand what information was evaluated, what actions occurred, and how conclusions were reached.
  • Explainability captures the reasoning behind recommendations so engineers can review outcomes, validate decisions, and understand the downstream implications.

Recommendations that cannot be reviewed or explained become difficult to trust, regardless of how sophisticated the underlying model may be. Trust develops over time as organizations gain confidence in how systems behave, how decisions are made, and how outcomes can be traced back to their source.

What actually determines success

Successful adoption of engineering AI depends on connected product information, strong traceability, disciplined governance, and clear decision processes. Much of this work predates AI. Engineering organizations have spent years connecting lifecycle data and building the foundations needed to understand how decisions and changes move across complex product environments. AI increases the value of those efforts by making context available at a scale that was previously difficult to achieve.

One of the biggest opportunities I see is AI’s ability to take on much of the repetitive work surrounding product development. That gives engineers more time to apply their expertise to solving engineering problems, innovating, and ultimately building better products.

The organizations that benefit most will be the ones that combine human expertise with connected product information, traceable decisions, and trusted engineering processes. Those foundations determine whether AI becomes another tool or a meaningful extension of engineering capability.


About the author

Rob McAveney brings a lifelong passion for technology to the CTO role at Aras. For the past 20 years, he has focused that passion on building rich software platforms that solve difficult business problems for major industrial companies. Rob acts as Aras’ technology visionary and provides design oversight for future PLM technology, while remaining grounded in the realities of configuration management, systems integration, and the many other challenges of delivering enterprise software. Prior to Aras, Rob led technical sales engagements for Eigner, an early entrant in the PLM market. He began his career at Boeing, where he gained a broad understanding of engineering and manufacturing systems and processes.