When does AI software work become qualified research? Start with the uncertainty.

“We are building with AI” is a product description. It does not tell a U.S. research-credit reviewer what technical uncertainty existed, how the team evaluated alternatives or which costs belong to the work.

A more useful opening is specific: “We did not know whether this retrieval design could meet the required accuracy and latency within the memory budget. We tested three approaches, recorded their failure modes and changed the design.” That is still not an eligibility conclusion. It gives a reviewer something concrete to investigate.

This article was researched on October 7, 2026. Its examples are fictional and explain a review method, not a rule that all work matching the example qualifies.

Ask what was unknown at the start

The research-credit rules examine technological uncertainty, the relevant business component and a process of experimentation for a permitted purpose: function, performance, reliability or quality. The regulations explain that uncertainty can concern capability, method or appropriate design; using computers does not itself establish qualified research. A successful result is not required. The substantially-all standard generally requires at least 80% of research activities, measured on a cost or other consistently applied reasonable basis, to constitute qualifying experimentation. Treasury Regulation 1.41-4(a).

The 2025 amendment also makes Section 41's expense gateway refer to domestic research or experimental expenditures under Section 174A. Passing that gateway does not complete the credit analysis. Public Law 119-21, Section 70302(b)(2).

For a software team, translate that into an interview before requesting a polished narrative. What outcome was the team trying to achieve? What did it know already? Why were available approaches insufficient? Which alternatives were actually evaluated? What records show the results?

Avoid allowing “we had never used this framework before” to stand in for technical uncertainty. Unfamiliarity, a tight deadline and uncertainty about customer demand describe real business challenges, but they do not answer the same question. Record them honestly alongside the technical facts so the preparer can make the distinction.

Work through a retrieval example

Imagine a company building an AI document-search service. Its target is to return an answer with supporting passages within 900 milliseconds on a defined evaluation set. The initial design loses relevant passages when long documents are split into fixed-size chunks.

The team compares fixed-size chunking, document-structure chunking and a hybrid retrieval approach. It keeps the evaluation set fixed, records retrieval failures and latency distributions, and identifies the relevant code revisions. One approach improves recall but exceeds the latency target. Another fits the latency budget but fails on documents containing cross-references.

The record is useful because it distinguishes the question, alternatives, observations and resulting decision. It is also useful engineering knowledge if the tax preparer ultimately excludes some or all of the activity.

Now separate neighboring work: changing button labels, adding routine billing screens, uploading existing documents and rolling out a standard vendor connector. Those tasks should retain their own descriptions. Their presence in the same release does not supply the experimental evidence that the retrieval work has.

The regulation's software examples distinguish evaluation of commercially available products and routine selection of supplied functions from qualifying experimentation. Applying that distinction to an AI integration is a factual analysis, not a categorical exclusion of integrations. Treasury Decision 9786, software examples.

Build a small evidence packet

For the fictional retrieval project, a useful packet would contain:

This is a recommended preparation structure. It is not an IRS-prescribed template, and completing its rows does not certify a claim. Its value is that a reviewer can trace each proposed conclusion back to the underlying work.

Keep failures in the packet. If the first approach never reached production, its experiments may still explain what the team learned and why the final design changed. Do not retrospectively rewrite the project's initial question to make the chosen solution appear inevitable.

Internal use needs an additional conversation

Certain software developed primarily for internal use is subject to a high-threshold-of-innovation test, including innovation, significant economic risk and commercial-availability conditions. The rules distinguish general administrative functions, third-party interaction, dual-function software and exceptions. “Our employees use it” is not a sufficient classification on its own. Treasury Decision 9786, internal-use software rules.

That is particularly relevant when an AI assistant serves several audiences. A finance assistant, a customer self-service tool and software used within a production process should not inherit one label simply because all three use the same model provider.

Give the reviewer the intended users, functions, commercial alternatives and the design assumptions at the beginning of development. If a product later gains an internal administrative use, record the chronology. Keeping those facts explicit is more useful than having a model guess the software classification from its name.

Costs require their own evidence

Activity analysis and expense analysis are separate jobs. The cost regulation addresses qualified services and contract research, including conditions on the research agreement. A development invoice's existence does not settle its treatment. Treasury Regulation 1.41-2.

For the retrieval example, preserve both the model-provider bill and any usage references identifying the experiments. Record shared costs, credits and production traffic separately. If part of a charge has no defensible project connection, leave that gap visible. A reviewer can investigate a missing allocation; a fabricated allocation is harder to unwind.

Likewise, a pull request can demonstrate a code change without measuring all the time behind it. Meetings, failed approaches and work outside the repository may matter. Conversely, a large volume of generated code can say little about human participation. Confirm the cost basis using the appropriate source records and people.

Use AI to make the review more inspectable

An AI assistant can help draft an evidence chronology, compare experiment notes or identify a claim with no supporting reference. Ask it to distinguish a direct statement from an inference and to retain the exact source links it used. Then let a person correct the interpretation.

For example, an assistant might suggest that three issues refer to the same latency experiment. A reviewer can accept the grouping, separate one issue involving production maintenance and add a missing evaluation report. The value is in the shorter route to a checked explanation, not in replacing the check.

Keep the commercial outcome visible too. Did the final design reduce failed searches, improve completion rates or lower cost per successful answer? Those measures inform product ROI. Tax qualification asks a different set of questions. A credible analysis can report strong operating value alongside uncertain or excluded tax treatment.

Proforma starts with the records, their coverage and the next questions. An initial evidence review can support the specialist's investigation, including manual preparation and supplied cost records. It does not automatically determine software eligibility or turn an AI subscription into a tax credit.

Sources and review scope

• Treasury Regulation 1.41-4: research qualification, experimentation, exclusions and records.
• Public Law 119-21, Section 70302: the amended domestic-expense gateway.
• Treasury Decision 9786: software examples and internal-use software rules.
• Treasury Regulation 1.41-2: qualified services and expense rules.
• IRS software examination guidance: supplementary historical examination context, expressly not a pronouncement of law.

Research checked October 7, 2026. The deduction rules under Section 174A and credit requirements under Section 41 remain separate analyses; state rules and financial-reporting treatment are outside this guide.