The Business Case for AI in HR: Build a Testable Proposal

The business case for AI in HR is strongest when it begins with a specific, measurable problem rather than with a technology. An HR team that can say "we spend roughly 12 hours a week sorting applications for roles with more than 100 applicants" has something to test. An HR team that says "we want to use AI" does not.

Tools like fenbs help teams record the decisions and approval criteria that make a pilot credible: who chose the scope, what evidence would count as success, and what the review process looks like. That record matters when you present results to leadership or defend a policy to employees. For documented examples of what HR AI pilots have actually produced, see AI in HR case studies.

Step 1: Start with a specific HR problem

Pick one task that costs measurable time or produces inconsistent output. Common candidates are initial resume screening for high-volume roles, answering repeat onboarding questions, drafting templated job postings, or generating first drafts of policy updates. A single, bounded task is easier to evaluate and easier to explain to stakeholders.

Avoid framing the case around capability ("AI can summarize documents") and frame it around the problem instead ("our HR team re-answers the same ten benefits questions every new-hire week"). The first framing invites feature demos. The second invites a discussion about whether AI actually solves the problem in your specific context.

Step 2: Set a baseline before you start

A business case without a baseline is an opinion. Before you introduce AI, record how the current process works: how long it takes, who does it, how often errors occur, and what quality looks like. Even rough numbers are better than none. If you do not have records, spend two weeks logging the task manually before starting a pilot.

The baseline is also your protection. If an AI-assisted process later produces a problem, you need to know whether that problem existed before. A baseline lets you say "error rate on draft job postings went from one in ten to one in four with this tool" rather than guessing whether things got worse.

Step 3: Choose a task with a clear person in the loop

An HR AI pilot is far easier to approve and defend when there is an obvious point at which a human reviews and approves the AI's output before it reaches an employee or a candidate. Resume scoring that a recruiter reviews before making any contact is lower risk than an automated system that sends rejections without human sign-off. Start with the version where a person is always in the review chain.

This is not just a risk management point. It also produces better AI output over time. A recruiter who reviews AI-generated screening notes and corrects them regularly will notice patterns in what the tool gets wrong and can adjust the criteria or the prompt accordingly.

Step 4: Assess the risks

HR work touches employment law, privacy law, and the rights of job applicants and employees. A business case that does not name the risks is not credible to legal and compliance reviewers. Work through the following before you write the proposal.

• Disparate impact: Could the AI tool produce outcomes that disproportionately affect a protected class? The EEOC's technical assistance on AI and the ADA covers hiring; review it at eeoc.gov.
• Employee data privacy: What employee data does the tool process? Does it leave the organization? State laws including the California Consumer Privacy Act apply to employee data in some circumstances.
• Vendor accountability: What does the vendor claim its tool does, and what evidence supports those claims? Vendor case studies are not independent audits.
• Reversal: If the tool produces a bad output that reaches an employee or candidate, what is the process for correcting it and who owns that responsibility?
• Transparency: Do applicants or employees know AI is being used? Several jurisdictions require disclosure.

Step 5: Define your approval criteria

Approval criteria answer the question: what result would justify continuing this pilot, and what result would cause you to stop? Write these down before you start. Examples: "error rate on AI-generated job postings must stay below 5 percent"; "recruiter review time on screened applications must drop by at least 20 percent"; "no AI-generated communication reaches a candidate or employee without a named HR reviewer."

Criteria written in advance are more credible than criteria written after you have seen the results. They also protect the people who ran the pilot. If leadership later questions whether the project succeeded, your pre-written criteria are the answer, not a post-hoc interpretation.

Step 6: Write the one-page proposal

A one-page proposal covers: the specific problem and why it matters now; the baseline measurement; the proposed AI tool or approach and why you chose it over alternatives; the review process that keeps a person in the loop; the risks identified and how you will manage them; and the approval criteria. Keep it to one page so reviewers have to engage with the substance rather than skim.

The proposal is also the foundation of the project record. Once approved, the criteria and decisions in it become the rules the pilot runs by. If those rules change, the change should be a conscious decision, not a gradual drift. For context on the broader landscape, AI in business intelligence and AI platforms for business cover how teams assess AI tools at a company level. For AI for business plans and AI brain for business, those pages address adjacent planning questions.

How to do this with fenbs

Set up the pilot project in fenbs before the pilot starts, not after.

1. Create a free account and add a project for the HR AI pilot.
2. Write the baseline in the project description: what the current process costs and how you measured it.
3. Add a task for each part of the pilot: the task the AI will assist, the review step, and the measurement approach.
4. Record the approval criteria in Decisions and rules, with the decision-maker named and a note of when they approved.
5. As the pilot runs, add comments to tasks with what you observe. Before the review meeting, save Where we left off so the team presents from a shared record rather than from individual notes.