What Happens If the AI Doesn't Perform as Expected?

Two months in and the AI tool your team adopted is giving you inconsistent results, wrong information, or outputs that need so much editing they are saving no one any time. The question is whether to fix it, change how you are using it, or walk away. That decision is harder to make clearly when you championed the tool to your ED, approved the spend, and now own the outcome.

The short answer is this: most AI failures in small nonprofits trace back to how the tool is set up and used, not to the tool itself. That does not mean every problem is fixable. It means your first job is to diagnose before you decide. Replacing a tool because of a setup problem wastes money and starts the cycle again. Staying with a misfit tool out of sunk-cost reluctance is its own kind of waste. The triage below gives you a structured way to tell the two apart.

Most AI underperformance is not a product problem

Most AI failures in small nonprofits trace back to inputs, workflows, or expectations rather than to the tool itself.

The sector data backs this up. The 2026 Nonprofit AI Adoption Report from Virtuous and NonprofitPRO found that 92% of nonprofits use AI in some form, but only 7% report major organisational impact. Only 4% have documented, repeatable AI workflows. The other 96% are using AI for isolated tasks, one person at a time, with no shared practice around it. The TechSoup 2025 AI Benchmark Report, drawing on responses from more than 1,300 nonprofit professionals, found the same pattern: most orgs are experimenting, not integrating.

That gap between adoption and impact is structural. The problem is almost always the setup, the workflow, or the original assumption about what the tool could do. That is the context your failure sits inside.

Diagnosing the failure: a triage framework

Before deciding whether to fix or cut, identify which of four failure categories applies, because the right response is different for each.

There are four named failure modes. Most AI underperformance in small nonprofits traces back to one of them, and three of the four are fixable without switching tools.

Input failure

Input failure is the most common and the most fixable. Symptoms: outputs are consistently wrong in the same way, generic, off-target, or producing hallucinations. The cause is almost always the prompt. Vague prompts with no role assigned, no output format specified, multiple tasks crammed into one request, and no examples provided will produce poor output from a capable tool.

The fix is prompt redesign, and it usually takes under an hour. Assign the AI a specific role: “You are a grant writer for a UK disability charity. Write this in plain English at a Year 10 reading level.” Specify the format: length, structure, tone. Break complex tasks into smaller sequential steps. Provide a concrete example of a good output. Add context the model does not have by default: the name of the funder, the size of the ask, the programme being described.

If the outputs are consistently wrong in the same way, and no one on your team has built a structured prompt, you have an input failure. Fix the prompt before drawing any conclusions about the tool.

Expectation failure

Expectation failure happens when the tool does something, just not the thing your org needed it to do. Symptoms: technically functional outputs that do not match the actual task. The cause is a use case that was never assessed against the tool’s real capability, often because a vendor demo showed the best-case scenario and your actual use case was different.

The fix depends on how wide the gap is. Sometimes the right move is to redefine the use case to match what the tool can actually do, and find a different solution for the thing it cannot. Sometimes the right move is to stop and acknowledge that this tool was bought for a job it was never going to do. Expectation failure is the category where the decision to cut is most defensible, because the gap is structural rather than correctable.

If staff describe the tool as “doing something but not what we needed,” start here.

Workflow failure

Workflow failure occurs when the tool produces acceptable outputs in isolation but those outputs sit unused or require more downstream editing than anyone anticipated. Symptoms: the AI produces something, but it never gets used without heavy rework; outputs pile up unreviewed; one person uses the tool and no one else does.

The cause is that the workflow around the tool was not redesigned when the tool was adopted. The AI was dropped into an existing process without thinking about where the output goes next, who reviews it, and who has the capacity to do that review.

The fix is workflow redesign: assign a review step, build a shared prompt library, define which tasks the tool owns and which tasks a human owns after it. If the integration with existing data systems is technically incompatible, that is a harder constraint and may warrant the cut decision.

Adoption failure

Adoption failure is a change management problem, not a technical one. Symptoms: usage is one person deep; results vary sharply between staff; one team member has quietly stopped trusting the tool’s outputs without flagging it to anyone.

The NTEN Tech Accelerate analysis shows that only 1% of nonprofit technology budgets goes to training. That funding allocation mismatch is a structural cause of this failure mode. The tool was rolled out, and nothing happened to help staff use it well.

The staff-confidence signal is worth checking directly: ask the person using the tool whether they trust its outputs. If the honest answer is no, and no structured onboarding or shared prompting practice has been put in place, you have an adoption failure. The fix is structured training and a shared prompt library. Not a new tool.

Is vendor support going to solve this?

For most off-the-shelf AI tools on standard plans, vendor support can confirm the product is working as designed, but it will not fix a prompting or workflow problem.

The practical support reality for a small nonprofit on a standard-tier AI plan is: self-service documentation, help-centre tickets with a 24-72 hour response window, and no dedicated account manager. Vendors fix confirmed bugs. They do not customise model behaviour for individual small-org customers, and they do not review your prompts.

The answer you will most often get from support is “the product is working as designed.” Which may be true. That answer does not tell you whether your prompts are the problem or whether your use case fits the tool’s capability. Those questions are yours to answer, not the vendor’s.

Contact the vendor if the tool is producing outputs that fall clearly outside its advertised capability range. When you do, document specific failure cases with examples before reaching out. Describe the input, describe the output, describe what you expected. Vague support tickets get vague responses.

For anything that traces back to input failure, workflow failure, or adoption failure, the fix sits inside your org.

How do you know when to stop?

Cut the tool when the failure mode is capability rather than setup, and when the cost of fixing exceeds the cost of switching.

Two questions help make this call. If you had not already paid for this, would you start now? And can you fix what is failing in less time than it would take to evaluate and switch to something else? If both answers are no, the decision is to stop. That is not a failure of the AI. That is information about fit.

The criteria for cutting are specific. The tool’s core task is not in its actual capability set. Integration with existing systems is not achievable or would cost more than switching. Usage costs at production scale are unaffordable compared to the pilot phase. Staff resistance persists after structured onboarding and process redesign. The vendor has not responded to documented support requests.

If none of those are true, the failure is more likely fixable. Staying with a tool while it is still in the fixable category is reasonable. Staying with a tool past that point because the spend is already done is a different calculation. The Candid AI equity guidance makes a related point: the fear of having made a bad decision should not drive further investment in the wrong direction.

One last signal worth checking before you decide: if a staff member has quietly stopped using the tool’s outputs without telling anyone, the tool has already failed in practice, regardless of what the licence says.

What do I tell my ED or board?

Frame it as a diagnostic outcome rather than a confession: you identified the problem, assessed the options, and are bringing a recommendation.

The framing for a board conversation is straightforward: “We identified that the AI tool was not performing as expected. We diagnosed the cause. We made a decision based on that diagnosis.” That is what careful stewardship of the budget looks like. A better story than “it did not work and we do not know why.”

If the board asks for context, the sector numbers help. The Virtuous data shows 92% of nonprofits using AI, only 7% reporting major impact, and only 4% with documented repeatable workflows. The sector-wide problem is process and governance, not products. Your org is not an outlier.

Prepare two scenarios before the meeting. If the recommendation is to fix and continue, bring a concrete change: the specific prompt redesign, the new review step, the shared prompt library. If the recommendation is to stop, bring a clear statement of what was learned and what a better-fit use case would look like. Either answer is defensible when grounded in the triage.

The board question that is hardest to face is whether the original tool selection was sound. It often was. The GivingTuesday AI Readiness Report found that around 15 staff is the threshold where most nonprofits first hire a technical or MERL person. A 14-staff org is exactly where informal tech ownership creates high digital risk. That is a structural feature of this org size, not a sign that the decision-maker failed.

Getting to a decision

Run through the triage categories in order, name which one applies, and use the two-question sunk-cost check to confirm the direction.

The sequence is: run the triage, name the failure category, apply the sunk-cost check, bring a recommendation to the ED or board. The downloadable triage checklist is the reusable artefact for that first step: a one-page document you fill in and take to the meeting, rather than reconstructing the diagnosis from memory.

If the failure is input or adoption, try the fix first. Both are solvable internally without a tool switch, usually within a few weeks of structured work. If the failure is workflow, the fix takes longer but is still solvable without switching. If the failure is expectation, the question is whether a redefined use case is worth the effort or whether stopping is cleaner.

The framing that holds throughout: the question is not whether to keep using AI. It is whether this tool, for this use case, in this workflow, is the right fit right now. Those are answerable questions. Running the triage is how you answer them.

For further support, the NTEN AI Resource Hub and the NTEN AI Governance Framework are the most sector-specific resources available for small nonprofits working through this kind of decision.