Should This Be AI? When to Use AI at Work—and When Not To
By Ryan Clement · Published
I used AI to help build a tool that might tell you not to use AI.
Start before anything gets generated
Over the last couple of years, I’ve spent a lot of time building tools and workflows with AI—figuring out where it helps in my work, where it creates more work, and where a person needs to stay involved.
I wanted to turn some of that experience into a useful starting point for others. The result is “Should This Be AI?”, a free task check on my website that helps people consider the work, the risks, and the safeguards before deciding where AI belongs.
To me, the conversation about “AI slop” should start before anything gets generated. Is AI appropriate for this task? Can someone verify the result? What happens if it is wrong?
Those questions matter whether you are preparing a weekly report, organizing board meeting notes, or following up after a sales call. Before deciding which tool to open, you need to understand what you are asking it to do.
Access to AI is not the same as knowing where it belongs
Blackbaud Institute and Edge Research surveyed 1,389 U.S. social impact professionals in March 2026. While 85% reported using AI at work, only about a third believed their organization used it very effectively. These are survey responses, not proof that adopting AI causes better organizational outcomes.
I would not read that as a reason to push everyone to use AI. I would read it as a reason to provide better guidance.
There is evidence of value, too. Gallup’s analysis of the same survey found that 65% of employees in organizations implementing AI reported a positive effect on their productivity and efficiency. Those are employees’ assessments of their experience—not a guarantee that any particular workflow will save time.
Both findings can be true. AI can help people, and people can still need support deciding when and how to use it.
Telling someone to “use AI responsibly” does not answer the practical questions they face. Which information can they enter? What needs to be checked? Is the output a draft, a recommendation, or something that will trigger an action? Who is responsible for approving it?
That is where I think the conversation needs to become more concrete.
Evaluate the task—not just the technology
When I look at a possible AI use, I start with the work itself.
“Use AI for reporting” is too broad. A report might involve pulling data, calculating totals, identifying changes, drafting an explanation, and recommending action. Those are different tasks. They should not automatically receive the same answer.
For example, I would use an established calculation or reporting system to produce totals from structured data. AI might then help draft an explanation of verified results. A person would still need to decide whether that explanation is accurate, relevant, and appropriate for its audience.
Sometimes the better solution is a spreadsheet formula, a template, or a straightforward automation. The National Institute of Standards and Technology’s AI Risk Management Framework Playbook explicitly encourages organizations to consider non-AI alternatives when evaluating a proposed use.
My practical test starts with three questions:
What part of the task actually needs AI?
Moving standard form responses into a spreadsheet is different from organizing inconsistent written feedback into draft themes. Do not add interpretation where fixed rules would do the job.
Can someone reliably check the result?
A summary of a public annual report has a source you can compare it against. A recommendation built on missing information or assumptions may be much harder to verify.
What happens after the output is produced?
A draft that stays with its author for review is different from a message automatically sent to a customer or a recommendation used to make a consequential decision about an employee.
The decision may be to use AI for one bounded part of a process while keeping the rest human-led. That is often a more useful conversation than deciding whether an entire department should “use AI.”
Human review needs to mean something
“Someone will review it” sounds reassuring. I would still ask what that review involves.
Does the reviewer have the original information? Do they understand the subject well enough to recognize a mistake? Do they have time to check the work—and the authority to stop it from being used?
NIST’s AI Risk Management Framework calls for human oversight processes to be defined, assessed, and documented. It also treats testing before deployment and during operation as part of managing AI risk.
Research provides another reason to be deliberate. A 2025 study presented at the CHI conference surveyed 319 knowledge workers and found that greater confidence in generative AI was associated with less reported critical-thinking effort. It was a self-report study, not proof that AI causes people to lose their thinking skills. But it raises a useful question about whether confidence in a tool changes how carefully people check its work.
My takeaway is that review should be specific enough to follow.
For a report, that could mean checking every figure against the source and distinguishing a documented change from a proposed explanation. For meeting notes, it could mean confirming that a discussion was not presented as a decision. For a sales-call summary, it could mean verifying that a customer’s interest was not rewritten as a commitment.
The standard should be more than “this sounds right.”
Guardrails can help turn an experiment into a repeatable process
A useful result once is a starting point. Before making it part of a routine, I want to know what needs to stay consistent and what should cause the process to pause.
Consider three common business tasks.
A weekly report
Before introducing AI, I would define the approved data source, the reporting period, the required sections, and who checks the final version.
I would also decide how to handle missing or conflicting information. Should the draft flag an incomplete figure? Should the process stop until the source is corrected? Who resolves the discrepancy?
Those decisions are part of the workflow. They should not be improvised each week.
Board meeting notes
I would distinguish between a working summary and the organization’s official record.
For an approved AI-assisted summary, my instructions would call for clear separation between discussion, decisions, and action items. Names, responsibilities, and deadlines would need to be checked against the original notes. Where something was not established, I would rather see “not specified” than a completed-looking answer.
Before any of that, the organization would need to approve the tool and the information being entered. A convenient summarization task is not a reason to skip that decision.
A sales-call summary
I would ask for the customer’s stated needs, unresolved questions, and agreed next steps—not a more optimistic version of the conversation.
The account owner would then check the summary before it entered the customer record or became a follow-up message. “Send additional information” should not quietly become “customer is ready to proceed.”
These are examples of how I would structure the work, not guarantees that a particular tool will perform it correctly.
The goal is to establish a process another person can understand: what goes in, what should come out, what gets checked, and what happens when something is unclear.
Measure the whole workflow, including the cleanup
I would not measure success only by how quickly AI produces a draft.
Blackbaud’s September 2026 article on evaluating AI agents makes a related distinction: completed actions alone do not establish useful results. Its discussion of customer research considers outcomes, supporter engagement, and operational quality together. That is guidance from a vendor studying its own product context, not an independent guarantee of effectiveness.
Include the time spent preparing the information, reviewing the output, correcting mistakes, and answering questions from the next person who uses it. Also consider whether the result is clearer and more useful than what you produced before.
A fast first draft is not much of an improvement if a colleague has to reconstruct its sources or rewrite its conclusions.
For a recurring task, start with a few representative examples—including incomplete or awkward ones. Compare the AI-assisted process with the existing approach. Look at both the effort required and the quality of the finished work.
Then keep checking. NIST’s framework treats monitoring, user feedback, incident response, and change management as ongoing parts of managing an AI system—not activities that end at deployment.
My practical rule is to reassess when the task, information, tool, or use of the output changes. A workflow approved for an internal draft should not quietly become an automated external communication.
Leaders have a responsibility to make the expectations clear
I do not think employees should have to interpret “use more AI” on their own.
Gallup’s July 2026 analysis found that clear plans for AI integration and active manager support were associated with higher employee engagement. The findings point toward the importance of how organizations introduce and support AI, rather than access alone.
For me, that translates into a leadership responsibility: define what good work looks like, explain where experimentation is appropriate, and make it possible for someone to raise a concern.
An employee should be able to say, “This did not save time,” “I could not verify the result,” or “I do not think this task belongs in AI” without that automatically being treated as resistance.
Those observations give you something useful to evaluate. They may reveal a training need, a weak process, or a task that should stay with a person.
The goal should be better work—not simply more AI use.
Start with one task
That is the purpose of “Should This Be AI?”
The form walks through a task, its risks, and the controls around it. Depending on the answers, the guidance may point toward human-led work, AI assistance, simpler automation, or a pause until important questions are resolved. It is a practical starting point—not authorization to use a particular tool or a substitute for your organization’s policies.
Try it with one task you do regularly. Describe the process, not confidential information. Then use the result to ask a better question about how that work should be done.
You still own the work, whether AI helped with it or not.