Artificial intelligence (AI) remains a major area of interest for research and development (R&D) tax credit claims. But one point is critical. Using AI is not, in itself, qualified R&D.
For AI-related work to support a credit under Section 41, taxpayers must show that the project involved technical uncertainty, technological experimentation, and a permitted purpose, such as improving software performance, reliability, quality, or functionality. Section 174A may affect the treatment of certain domestic R&D qualified research expenditures (QREs), but it does not replace the Section 41 qualification analysis.
A brief note on technical uncertainty: Technical uncertainties or unknowns exist when, at the outset, the team does not know whether it can achieve the intended result, which design will work, or which method to use. For AI projects, that uncertainty may involve model performance, latency, reliability, data quality, architecture, or deployment constraints — not merely commercial usefulness.
Defensible AI projects generally go beyond deployment, configuration, or ordinary business use. They involve a documented attempt to resolve a technical question where the correct design, method, or capability was uncertain at the outset.
Examples may include:
Model optimization and hyperparameter tuning
Systematic experimentation to reduce loss, latency, hallucination rate, token cost, or inference time, where the appropriate technical approach was not readily determinable
Fine-tuning or model adaptation under technical constraints
Testing alternative training data sets, modeling approaches, evaluation metrics, or model variants to improve a specific technical function
Novel architecture or orchestration design
Developing custom attention mechanisms, proprietary routing logic, agentic workflows, or mixture-of-experts approaches to solve a technical performance problem
Synthetic data engineering
Designing algorithms to generate high-fidelity synthetic training data when real-world data is insufficient, restricted, imbalanced, or unavailable
Retrieval-augmented generation architecture
Experimenting with chunking strategies, embedding models, vector database design choices, re-ranking logic, or latency controls to improve reliability and performance
Hardware-software co-design
Optimizing inference engines, quantization methods or deployment architecture so specific large language models (LLMs) can run in constrained environments with limited graphics processing memory or computing capacity
Not every AI initiative is R&D for tax credit purposes. Activities involving implementation, routine configuration, or ordinary data handling generally present greater qualification risk.
Examples include routine application programming interface (API) integration, basic prompt drafting, manual data labeling, clerical data cleanup, deployment of an existing model as-is, and business process automation without technical experimentation.
These activities may be valuable. But value alone does not establish qualified research. The key question is whether the work was directly tied to resolving technical uncertainty through experimentation.
AI tools developed primarily for internal general and administrative functions require special attention. Internal-use software (IUS) must meet the higher threshold of innovation, in addition to the standard four-part test.
That means an internal human resources (HR) chatbot, finance assistant, or knowledge management tool may face a higher documentation burden than software for customers.
The IUS standard is not a fixed percentage test. Regulations focus on whether the software is intended to produce a substantial and economically significant reduction in costs, an improvement in speed, or other measurable improvements.
The direction of travel is clear. R&D credit claims increasingly require contemporaneous project-level support. For tax years beginning after 2025, Section G of Form 6765 generally requires taxpayers to report software information, subject to the form instructions and applicable exceptions.
AI software development should be documented with a clear nexus among:
Technical uncertainty
A defined technical question, such as whether the team could achieve sub-100-millisecond latency for a retrieval-augmented generation pipeline while maintaining response accuracy and source grounding
The experimental process
Evidence of the alternatives tested, such as A/B tests, benchmark results, failed model variants, architecture diagrams, sprint notes, version logs, and evaluation metrics
The QREs
Time and costs tied to the uncertainty, such as developer, machine learning engineer and cloud engineering hours spent resolving the documented technical issue
AI can support an R&D tax credit claim, but only when the work reflects technological experimentation rather than ordinary implementation.
The key question is not, “Did we use AI?” Instead, ask, “What technical problem did we attempt to resolve, and what evidence shows how we resolved it?”
If the engineering record does not include alternatives, iterations, failures, or technical trade-offs, the project may be difficult to defend as qualified research.
Optimize your tax strategy. Schedule a complimentary R&D consultation with Randy Eickhoff, CPA, Founder & Head Coach of Acena Consulting, for expert guidance.
Register for our free monthly webinar, next on May 26, 2026: Cracking the (Tax) Code for R&D.
Visit our Acena Events page to sign up for our newsletter and stay abreast of all upcoming events.
Follow Acena on LinkedIn and X for the latest industry-specific incentives and tax policy updates.
//
Edited by Laura Whittenburg, MSBME, Sr. Technical Writer at Acena Consulting. Photo courtesy of Vicchi on Flickr.