SR&ED, AI and software: where the real technological uncertainties lie

Since the rise of large language models, many companies claim to "do AI." For a firm, the challenge is to tell apart those that consume a mature AI technology from those genuinely pushing a technological limit. Both can create great business value; generally only one of the two is eligible for SR&ED.

The underlying test hasn't changed

AI doesn't change the SR&ED criteria. The question remains: was there a technological uncertainty that couldn't be resolved by applying existing knowledge and tools, and was it addressed through systematic experimentation? Wiring a performant, well-documented model into a product, however useful, doesn't by itself create that uncertainty.

What is generally not SR&ED

• Calling an AI API. Integrating a commercial model (text generation, vision, transcription) through its documented interface, as intended.
• Prompt engineering alone. Tuning instructions to get better responses is usually use optimization, not R&D.
• Routine retraining. Retraining a model on new data with a proven pipeline, with no unforeseen technical obstacle.
• Assembling known building blocks. Wiring a vector store, a model and an orchestrator using established recipes, when everything works as expected.

Where the real uncertainties hide

Eligibility appears as soon as the technology's behavior becomes unpredictable and you have to experiment to reach a technical result that wasn't guaranteed. A few common areas:

• Reaching an accuracy or reliability threshold that standard approaches couldn't deliver, on a particular domain or dataset.
• Performance and cost at scale: driving latency or inference cost below a target where no known method produced the result directly.
• Difficult data: scarcity, noise, imbalance or bias that break the usual techniques and demand new strategies.
• Model adaptation: fine-tuning, distillation or custom architectures when documented approaches don't converge or don't hold up in production.
• Integration under constraints: making a model work within limits of memory, embedded hardware, real time or privacy that had no established solution.
• Evaluating non-deterministic behavior: designing methods to measure and stabilize inherently variable outputs.

The right reflex isn't to ask "Do you use AI?" but "What did you try that didn't produce the expected result, and what did you have to invent to get there?" SR&ED lives in that gap.

The "it worked on the first try" trap

When a commercial model meets the need directly, there's often no uncertainty, and that's fine. SR&ED is found in projects where a limit had to be worked around: the model hallucinated on the client's domain, latency was unacceptable, accuracy plateaued, the data didn't lend itself to known methods. It's these frictions, and the experiments run to resolve them, that make the claim.

Why these files are both valuable and risky

AI projects engage expensive profiles and many hours: well documented, they yield substantial claims. But they're also files the CRA examines closely, precisely because a lot of "use" gets presented as R&D. Hence the importance of rigorously separating eligible experimentation from routine integration work, and of backing the narrative with a solid technical trace.

A technical eye that knows the boundary

This is exactly the kind of file where my background makes a difference: over 20 years in software development and a concrete understanding of AI technologies let me draw the line between use and R&D, identify the genuinely eligible uncertainties, and document them defensibly, in support of your firm.