AI in Engineering Compliance: Observations for ASME and API Standards Committees

The history of technical standards is, in part, the history of the tools the standards had to absorb. Paper drawings gave way to CAD, and standards committees worked carefully through what that change meant for review, signoff, and revision control. CAD gave way to digital engineering and integrated models, and the same committees worked through what that change meant again. Cloud collaboration came next, raising questions about access control, document custody, and audit traceability across distributed teams.

Each shift produced a long conversation. New language was added to existing codes. Some sections were rewritten entirely. Most of it happened in the deliberate, multi-year cadence that standards development organizations have always used, and that has served the industry well for as long as the codes have existed.

AI-assisted review is the next entry in that sequence. It is not a disruption of the standards conversation. It is a continuation of one that has been going on for decades.

It is also worth being honest about what makes this particular shift novel. Earlier tools digitized the work without changing the locus of decision-making. CAD did not interpret a drawing. Cloud collaboration did not raise a finding. Document management did not reason about a clause. The engineering judgment, the review call, and the compliance verdict all stayed in the same place.

AI-assisted review participates in those activities differently. It can parse a drawing against an applicable standard, surface a potential non-conformance, cite a clause, and assign a severity. It does not perform the inspection, and it does not make the final call, but it actively participates in the interpretive layer in ways earlier tools did not.

That is what makes the governance conversation around AI specifically worth having. The broader pattern of "tools evolving" is familiar. The specific mechanics of how interpretation, evidence, and accountability should flow when AI is in the chain are genuinely new ground.

Some context on what has settled in practice is probably the most useful contribution this article can make. Operators using AI-assisted review for engineering compliance, regulatory compliance, and engineering documentation have converged, across vendors, on a recognizable set of patterns.

In both workflows, the reviewer remains the named accountable party. The difference is what the reviewer's hours are spent on. In the traditional model, much of that time goes to clause lookup, cross-referencing, and document review assembly. In the AI-assisted model, the reviewer focuses on judgment, override decisions, and the cases that genuinely need human review.

The compliance record in either case is the integration of standards interpretation, reviewer judgment, and supporting evidence. AI does not replace any of those layers. It supports the layer that was always going to be the documentation bottleneck. AI compliance management at the operator level is shaping up to be less about replacing existing systems and more about adding a verification and traceability layer over them.

When AI-assisted review surfaces a finding, the questions that immediately follow are not new. They are the same questions a reviewer has always asked about any finding raised by any source. Why was this flagged. Which clause does it reference. Which revision of the standard applies. Which document or drawing was being reviewed.

What is new is the rigor with which these questions are being answered. Operators evaluating AI compliance software and AI document review platforms are increasingly treating traceability as a non-negotiable. A finding without a clause citation is not a finding. A clause citation without a source quote is incomplete. A source quote without a link to the specific document revision is not auditable. The bar has risen, and AI-assisted systems that meet the bar are setting a useful baseline for what defensible engineering compliance documentation looks like.

A concrete example helps illustrate why explainability has become non-negotiable. A piping package reviewed against ASME B31.3 and the corresponding owner specifications may generate dozens of findings on a single drawing set. Many of those findings are traceability questions rather than engineering questions: which clause governs this fitting class, which revision of the owner spec was in force when the line list was issued, which exception applies for the service category. When AI surfaces those findings with the citations attached, the reviewer can clear them in seconds. When AI surfaces those findings without traceable reasoning, the reviewer has to redo the work the AI was supposed to save.

Engineering compliance has always required findings that can be defended, not just findings that can be generated. AI-assisted review does not change that requirement. It raises it.

Explainability is becoming a stricter requirement than accuracy alone. A finding that is correct but cannot be explained is harder to defend than a finding that is wrong but transparent in its reasoning. The first hides the failure mode; the second makes it visible. Operators have largely settled on the view that explainable AI is not a feature, it is a precondition for using AI in compliance work at all.

The NIST AI Risk Management Framework and related external frameworks are part of the broader context for these conversations, and several operators reference them in their internal governance documentation. The point is not that any one external framework should be adopted wholesale, but that the broader industry conversation about responsible AI is informing how compliance teams think about AI traceability and AI risk management within engineering workflows.

Of all the patterns that have emerged from AI-assisted compliance review in production, three of them have surprised the operators using them more than the rest. None of them were the predictions that dominated the early conversation about AI in engineering work.

None of these surprises invalidate the broader principle that AI assists rather than replaces. They refine it. The value AI is actually delivering in engineering compliance automation is not the value the industry expected it to deliver two years ago, and the gap between expectation and reality is itself a useful input to the standards conversation.

The accountability question is the one most often raised when AI enters a compliance workflow, and it is also the one with the clearest current answer in practice. Across operators using AI-assisted review today, the named human reviewer remains the accountable party for every approval, override, and sign-off. AI is treated as an informational layer, not a decisional one.

This is not a workaround. It is a deliberate alignment with how engineering accountability has always worked. The engineer of record signs the design. The API authorized inspector signs the inspection report. The compliance reviewer signs the conformance finding. The AI-assisted layer prepares the evidence; the human carries the credential, the judgment, and the accountability.

What changes operationally is the reviewer's working pattern, not the reviewer's role. The reviewer spends less time on lookup and more time on judgment. That shift is consistent with what experienced engineers have argued for years: the senior reviewer's value lies in interpretation under ambiguity, not in clerical pattern-matching against a standards library.

Some practices have converged enough across operators that they are starting to look like emerging norms. Other questions remain genuinely open, and the industry is still working through them in real time. Both lists are short, on purpose. The honest report on AI-assisted compliance in 2026 is that we know more than we did two years ago, and we have plenty more to work out.

The convergence on the left side of the matrix has happened largely without coordination. Operators arrived at similar standards compliance practices independently, often by working backward from what their auditors required, what their PMC teams accepted, and what their regulators expected. That convergence is itself a useful signal. When multiple parties reach the same operational conclusions without coordinating, the conclusions tend to reflect real underlying constraints rather than convention.

The open questions on the right side are different. They are not stuck because the industry is avoiding them. They are open because they are genuinely hard, and because they sit at the intersection of code language, operator practice, vendor implementation, and regulatory expectation. These are the questions where standards interpretation conversations tend to be the most productive, and where the careful pace of standards governance is, on balance, a feature rather than a constraint.

None of the observations above are meant to argue that anything in particular should change. The point is more modest: there is a body of operator practice forming around AI-assisted compliance review, and some of what is forming may be useful context as standards committees continue the work they have always done.

The engineering standards community has earned its reputation for deliberate, careful adoption of new tooling. Paper drawings did not become CAD overnight, and CAD did not become integrated digital engineering overnight. The right pace for absorbing AI into the standards conversation is probably the pace standards bodies are already setting. What operators can usefully contribute is concrete information about what is being tried, what is working, and what questions are emerging from real workflows.

This article is offered in that spirit. Not as a recommendation, and not as a vendor position. As a field report from the operator side, in service of a conversation that the standards community has always handled with care.