AI and machine learning development is one of the most active areas of SR&ED claims in Canada — and one of the areas the CRA scrutinizes most closely, particularly since 2026 guidance sharpened the line between eligible model development and routine application of existing tools.
What Typically Qualifies
- Developing novel model architectures or training approaches when existing published methods don’t address the specific technical constraints involved
- Solving genuine data or performance limitations — for example, achieving reliable accuracy with limited, noisy, or highly imbalanced training data where standard techniques fail
- Systematic experimentation with model structure, feature engineering, or training methodology to resolve a specific, unpredictable technical obstacle
- Adapting models to operate reliably under real-world conditions that differ meaningfully from the conditions they were originally validated on
What Typically Doesn’t Qualify
- Fine-tuning a pre-trained, off-the-shelf model using documented, standard procedures for a well-understood use case
- Prompt engineering or configuration of a third-party AI API without resolving underlying technical uncertainty
- Standard MLOps work — deployment pipelines, monitoring dashboards, routine retraining on schedule
- Applying a known model type to a new but unremarkable dataset where the outcome was reasonably predictable
Where 2026 CRA Scrutiny Has Increased
Reviewers are increasingly distinguishing between teams that genuinely couldn’t predict whether an approach would work — and documented that uncertainty as they went — versus teams applying widely-known techniques and labelling the work as R&D after the fact. Claims built on contemporaneous experiment logs, ablation results, and documented failure analysis hold up far better than claims reconstructed at filing time.
A Useful Framing
Ask whether a competent ML engineer, using published research and standard libraries, could have predicted your model’s behaviour without running the experiment. If the honest answer is no — because the problem’s data characteristics, scale, or constraints genuinely broke standard assumptions — the work likely involved real technological uncertainty.
