Your Team Uses AI Every Day. Does Any of It Qualify for the R&D Credit?

TL;DR

• Simply subscribing to and prompting AI tools generally does not qualify for the R&D credit, because there is usually no technological uncertainty and no process of experimentation in typing a prompt.
• Developing, integrating, fine-tuning, or engineering around AI, where your team is solving technical problems with uncertain outcomes, may qualify under the same four-part test that governs any R&D claim.
• Many companies outside the software industry are doing potentially qualifying AI work right now without realizing it, often inside larger engineering and product development projects.

The question owners are suddenly asking

Two years ago, AI came up in eligibility conversations occasionally. Now it comes up in nearly all of them, usually in one of two forms. Either "we use AI constantly, so surely something qualifies," or "we are not an AI company, so none of this applies to us." Both instincts tend to be wrong, and the difference comes down to the same rules that have always governed the research credit under IRC Section 41.

The short version: the credit rewards technical problem-solving with uncertain outcomes. It does not reward the purchase of powerful tools. Where your company's AI activity falls on that line depends on what your people are actually doing.

The four-part test, applied to AI work

Every R&D claim runs through the four-part test in Section 41(d) and Treasury Regulation 1.41-4. Applied to AI work, it looks like this:

Permitted purpose. The work must aim at a new or improved product, process, or software component. Building an AI-assisted quoting engine for your business can be a business component. Asking a chatbot to draft an email is not.

Technological in nature. The work must rely on principles of engineering, computer science, or the physical sciences. Model integration, data pipeline design, and control-system logic generally do. Prompt-writing by itself generally does not.

Technical uncertainty. At the outset, your team must be uncertain about capability, method, or design. "Can an off-the-shelf vision model detect defects on our specific parts, at our line speed, under our lighting?" is uncertainty. "Which subscription tier should we buy?" is not.

Process of experimentation. The team must systematically evaluate alternatives: testing configurations, comparing approaches, iterating on failures. Failed attempts can still count. This is often where AI projects show their strength, because real integration work tends to generate exactly this kind of iteration.

What may qualify

Depending on the specific activities, documentation, and facts, work like this can be a candidate:

A robotics integrator tuning a machine-vision model to inspect custom parts, iterating on camera placement, training data, and rejection thresholds until the cell hits a reliable defect-catch rate. A custom manufacturer developing an AI-assisted process to predict tooling wear or optimize machining parameters, where nobody knew at the start whether the approach would work on their equipment. A smart home integrator engineering custom logic that makes third-party AI assistants drive complex whole-house scenes reliably, resolving conflicts no off-the-shelf configuration handled. An engineering firm building and validating a machine-learning workflow to accelerate structural analysis, testing it against known results before trusting it.

The pattern in each: an uncertain technical outcome, alternatives evaluated systematically, and engineering or computer science doing the heavy lifting. Note also that qualified research expenses can include not just wages and contract research but, in some cases, amounts paid for the right to use computers in qualified research, which is worth discussing with a specialist if significant cloud compute sits inside a development project.

What generally does not

Subscribing to AI tools and using them as delivered. Prompting a chatbot for content, code snippets, or research, however sophisticated the prompts. Routine configuration choices with no technical uncertainty. Training your staff to use AI products. Adapting an existing tool through settings the vendor already provides. These activities may be smart business, but they lack the uncertainty and experimentation the credit requires.

One nuance worth knowing: your developers using AI coding assistants inside a genuine development project does not, by itself, disqualify that project. The test looks at whether the project involves technical uncertainty and experimentation, not at which tools the team used along the way. This is an area where formal guidance is still thin, so careful, project-level documentation matters, especially as the IRS moves toward more detailed reporting of business components on Form 6765.

Where to go from here

If your company has shipped AI-adjacent work in the last few years, the honest answer to "does it qualify?" is that it depends on facts a short conversation can usually surface: what was uncertain, who worked on it, and what the iteration actually looked like. Strata's initial assessment is $0, and it is designed to give you a grounded answer before you commit to anything. Talk to our team.

This post is for informational purposes only and does not constitute tax or legal advice. Consult a qualified tax professional regarding your specific circumstances.