We machinists are conservative people. That is not a weakness. It is earned.
For thousands of years, people shaped metal into useful things by learning from failure. A blunt edge. A broken tool. A ruined part. The feedback was immediate. The consequences were physical and irreversible.
That instinct has not changed. A wrong decision on a titanium aerospace component does not produce a blunt edge. It produces a crashed spindle, a scrapped part, and a very difficult conversation with a customer.
The industry is excited about AI in CAM. The machinists I know are taking their time. So am I. Not to dismiss it. But to evaluate it with the same rigour I would apply to any process I am about to trust with a mission-critical part.
One Number Worth Knowing Before We Start
In 2025, researchers at the University of Maribor published a systematic review of peer-reviewed studies on AI in CAD-CAM integration. Their search covered 25 years of published literature, from 2000 to 2025. The 51 studies that met their inclusion criteria were published between 2002 and 2025.
Their finding: only 3 out of 51 studies used experimental machining as their primary research methodology. The review defines experimental machining as practical validation through CNC machine testing. That is 5.9%. The remaining studies relied on AI and machine learning modelling, simulations and algorithm validation, system architecture development, or analytical contributions. The authors concluded that the lack of real-world testing weakens reproducibility and comparability across the field.
That is not an anti-AI finding. It is an honest description of where the published research literature stands as of today.
Commercial deployment tells a different story in some areas. Genuine time savings on prismatic and 3+2 work, when paired with experienced review, are documented and consistent. Results on complex or novel parts are more variable. That picture, useful in a defined range and less reliable outside it, is precisely what limited real-world testing would lead you to expect.
Hold both realities in mind as we examine what is actually available and what is being claimed.
Historical attempts at automation in CAM
The idea that CAM software should recognise a part and generate machining strategies automatically is not new. It is decades old.
The first systematic attempt to automate NC programming dates to 1956, when MIT began developing APT, Automatically Programmed Tools. APT automated the translation of programmer instructions into machine code. The programmer still described every operation. Recognition was not automatic. Strategies were not generated.
Feature Based Machining, or FBM, went further. Products built on geometric feature recognition followed by deterministic rule application earned strong reputations in high-volume environments. FBM attempted to identify standard manufacturing features, pockets, holes, bosses, slots, directly from CAD geometry and assign machining strategies to each feature automatically. For families of similar prismatic parts, FBM delivered real gains.
So why is the programmer shortage still the industry's most persistent problem?
Because FBM is not intelligence. It is recognition followed by rule application. Change the material from aluminium to Inconel, move from a vice to a soft jaw, and the rule may no longer apply. The software does not know that. It applies the rule anyway, or fails, or asks the programmer to intervene. Which the programmer typically does. Because in regulated environments, the cost of an unattended error exceeds the cost of verification.
This pattern is not unique to machining. Before modern AI arrived, rule-based automation was attempted across multiple fields: medical expert systems, ERP workflow engines, code refactoring tools. In every case, three things happened consistently. The automation worked well in narrow, well-understood situations. The rule base fell behind evolving practice. And user trust depended entirely on the system's transparency and the ability to override it.
MYCIN, the expert system developed at Stanford through the 1970s, is the best-documented case. A blinded evaluation published in the Journal of the American Medical Association in 1979 found that MYCIN's antibiotic treatment recommendations were rated as acceptable by evaluating infectious disease experts at least as often as those of Stanford faculty physicians. MYCIN was never deployed in clinical practice. Not because it was inaccurate. Because workflow integration, the burden of maintaining the rule base, and accountability requirements stopped it.
The parallel to AI-generated toolpaths in an AS9100 environment in 2026 is structural, not coincidental.
What has changed in the current generation is not intelligence. It is the speed and breadth of automated decision-making. Current AI-CAM systems span three broad architectures, described in more detail below. This grouping is my own analytical framework, not an established industry classification: Pattern-driven systems that learn from geometry and historical programs, Knowledge-driven systems that formalise machining decisions into structured workflows, and Physics-based systems that model real machine behaviour rather than theoretical toolpaths. These architectures differ in how they reason. Some use statistical pattern matching. Some follow expert rules like evaluating moves. Some incorporate physics models for cutting parameters. All three have limits. Those limits are not always visible to the user.
AI systems can retrieve and reproduce theoretical machining knowledge instantly. They cannot tell you what happens when your workpiece shifts 0.03mm in the fixture. Those are not the same capability.
The Label That Covers Everything and Explains Nothing
The label "AI in CAM" is a buzzword. Not because nothing works. But because the label is applied so broadly that it has stopped carrying reliable information. Deterministic rule-based systems, statistical pattern recognition, physics-informed machine learning, and large language model assistants are all marketed as "AI in CAM." They are not the same thing. They do not carry the same risks. They do not deliver the same value.
After conversations with people across the industry, vendors, resellers, and users, and supported by independent survey data, two patterns emerge consistently.
The first is adoption pressure. A 2025 global survey by Thoughtworks and Censuswide found that 56% of executives reported feeling competitive pressure to adopt AI quickly, regardless of whether they had defined what they needed it to do. A separate 2024 survey by ABBYY, a vendor in the intelligent automation space, reported that 63% of IT leaders expressed concern about being left behind. The ABBYY survey was vendor-sponsored, a methodological limitation the authors themselves disclosed. The directional consistency across both sources is relevant even accounting for that limitation. In manufacturing, this pressure translates directly into CAM. Shops feel compelled to be seen adopting AI before they have defined what problem they need it to solve. Deployments without clear objectives underperform relative to those with defined goals, though controlled comparative studies on this specific question remain limited. In aerospace manufacturing, underperformance is not only wasted budget. It is compliance exposure.
The second pattern is more disciplined. Larger and more digitally mature manufacturers often come to AI in CAM with specific targets in mind: cycle time reduction, tool life extension, programmer productivity, scrap reduction. They are running pilots tied to defined goals and measuring outcomes against real numbers.
Both patterns are present in the market at the same time. This article is written for both audiences. If you are in the first group, the use-case guide below will help you define what you actually need before you evaluate anything. If you are in the second group, second part of this article covers the tests that will tell you whether a specific system belongs in your controlled process.
What Are You Actually Trying to Solve?
Before evaluating any system, one question is worth answering honestly: What problem are you actually trying to solve?
The "AI in CAM" label covers at least five different use cases. A system designed for one will not serve the others.
Programming faster on prismatic work.
You want to reduce the time from CAD model to ready-to-run program on familiar geometry. The AI layer analyses the part, proposes a machining plan, strategy, operation sequence, tool selection, and cutting parameters, and hands that plan to your existing CAM platform's conventional kernel for toolpath motion computation. The AI decides what to machine and how. The CAM kernel computes how to move. This is where AI-CAM systems currently deliver their most documented value.
Real-time feedback from the machine.
You want the system to monitor what is actually happening during the cut, spindle load, vibration, tool wear, and adjust parameters without the programmer making every decision. Some systems have achieved early commercial deployments of this capability using physics-informed machine learning combined with sensor integration, with real-time monitoring and parameter adjustment available from more than one provider. It requires sensor infrastructure and process integration that most shops do not yet have in place. This is the most technically ambitious use case and the furthest from widespread production deployment.
Reusing your own historical knowledge.
You want to stop starting from scratch every time a similar part comes through. The AI recognises geometric similarity to past work, retrieves what worked, and adapts it to the new part. These systems mine your existing CAM data, run on-premise to protect your data, and surface suggestions linked to validated parameters from the source job. The value is not just speed. It is preserving accumulated machining knowledge before it retires with the programmer who holds it. But there is a condition these technologies rarely state: The system can only be as good as the programs it learns from. If your historical programs reflect average practice, the AI will recommend average practice. The quality of the output depends entirely on the quality of the knowledge you have put in.
Faster quoting and design review.
Your bottleneck is not programming. It is estimating. Jobs are lost or wrongly priced because quoting takes too long or relies on experienced guesswork. Systems in this category combine DFM analysis, automated estimating, and operation planning to accelerate the front end of the workflow.
AI copilots and chatbots.
This category is the most misunderstood and the most widely deployed right now. These are not machining decision systems. They do not generate toolpaths or suggest strategies. They help programmers use the CAM software itself: answering questions in natural language, navigating menus through voice or text commands, adjusting parameters like feeds and speeds across multiple operations, and surfacing relevant documentation or training content instantly. Major CAM platforms are integrating these assistants directly into their products. Their primary function is software navigation and knowledge retrieval, not autonomous machining strategy generation.
Some technologies use the copilot label for systems that go further, proposing machining strategies for individual features. Where a technology generates strategies rather than assists navigation, it belongs in the programming acceleration category regardless of what it is called.
A chatbot that tells you how to create a pocket operation in your CAM software is not the same as an AI that decides how that pocket should be machined.
Conflating the two is how inflated expectations get built.
A Question that Marketing Never Answers
Most commercially deployed AI-assisted toolpath generation systems deliver their strongest results in 2.5 axis, prismatic, and 3+2 work. Limited publicly available, independently validated evidence currently exists for reliable autonomous toolpath generation for 3D contouring of complex sculptured or freeform surfaces: mold inserts, medical implants, or aerospace components requiring continuous engagement control along changing curvatures.
That domain still relies on traditional CAM surface strategies guided by experienced programmers using mature CAM tools. The AI layers accelerate planning and parameter selection around those strategies. They have not replaced skilled surface programming on complex geometry.
A shop machining a prismatic aluminium bracket and a shop machining a mold may both describe their work as "3-axis milling." They are not in the same situation. The AI tools that help the first shop significantly have not demonstrated the same reliable performance for the second.
The newer systems do add real things. The most meaningful architectural difference is this: where FBM sees isolated features and applies pre-built templates to each one, current AI-CAM systems analyse the part as a whole, generating strategy across the entire component rather than feature by feature. That holistic approach handles variability better than FBM, and the difference is real, particularly on parts where features interact in ways a rule library cannot anticipate. DFM and quoting integration are genuine improvements.
But systems that learn from historical data carry a limitation that is rarely discussed. If the programs in that history reflect average or below-average machining practice, the system will learn and recommend that same average practice. The AI does not know the difference between a well-considered toolpath and a mediocre one. It only knows what it has seen.
And it is worth remembering that many AI-first products in this space remain in closed beta or early commercial access. The industry is evaluating intentions and demonstrations as much as deployed capability.
This raises a question that the marketing rarely addresses. If the current generation of AI-CAM systems primarily delivers value in 2.5 axis, prismatic, and 3+2 work, how different is the practical output from mature, well-implemented feature-based machining systems that have existed for years?
The architectural difference is real. On simple prismatic work, it rarely surfaces. FBM's limitations, the inability to reason across interacting features, the brittleness when conditions change, do not appear on parts that were always within FBM's comfortable range. On that class of work, both FBM & AI based approaches produce usable programs. The architectural advantage of AI-CAM becomes visible as part complexity increases and features begin to interact in ways a rule library cannot anticipate.
The honest question for any machine shop is whether the work they actually do stresses that advantage enough to justify the transition.
Where the gap becomes visible is in the evidence. Most AI-CAM value today is accompanied by marketing vocabulary that suggests transformative capability. The independently validated evidence reviewed for this article suggests incremental improvement within defined domains, genuine architectural progress that has not yet been proven at scale on the complex work where it would actually matter the most.
What Happens When It Goes Wrong
The gap between a toolpath that passes simulation and a decision your process can actually defend matters most when the stakes are highest.
In aerospace manufacturing, any AI-CAM system operating outside its validated domain does not produce a wrong answer you can see. It produces a wrong answer that passes geometric checks, gets approved, reaches the machine, and reveals itself only in scrap, rework, or an audit finding you cannot defend.
When that happens, the investigation does not ask whether the toolpath was geometrically sound. It asks whether your process was controlled, validated, and traceable. It asks who reviewed the decision, what authority they held, and what they documented. It asks questions that most current AI-CAM deployments have not been set up to answer.
That is not a technology problem. It is a process problem. And it is the problem that AS9100, AS9102, FAI, and PPAP were designed to surface.
AS9100 Rev D, the current revision of the quality management standard for Aviation, Space and Defence organisations, requires documented controlled processes for product and service realisation, including evidence of conformance and traceability throughout the manufacturing workflow. AS9102B, the Aerospace First Article Inspection standard, requires that the first production article be inspected and documented against a defined manufacturing plan that includes the tools, processes, and parameters used. PPAP, the Production Part Approval Process developed in the automotive industry and formally adopted by many aerospace primes as a supply chain quality requirement, demands evidence that a manufacturing process can consistently produce a part meeting design requirements.
None of these standards prohibit the use of AI in manufacturing planning. But all of them require that whatever process produces the manufacturing plan be controlled, documented, and traceable to a qualified decision-maker. A toolpath generated by an AI system and reviewed by a qualified programmer, with that review documented, is defensible. A toolpath generated by an AI system and approved without documented review is not, regardless of whether it is geometrically correct.
The second part of this article covers the tests you can run on any AI-CAM system before you trust it with a mission-critical part, a decision framework that maps AI capability to work type and risk, and what is actually required of you before you certify anything an AI system touches.