AI Guardrails for HR: What HONO HR Assistant Refuses to Answer

HONO’s HR assistant does not answer every question it is asked. Some questions it answers fully. Some it refuses. Some it passes to a human being.

Those are not accidents. Every one of them is a design decision.

This article explains how HONO makes those decisions. It covers the three checks every question passes through, the four kinds of requests the system will not help with, and two real cases from production where the rules got it wrong and had to be fixed.

Two questions, two very different answers

Here are two real questions asked by two employees using HONO’s HR assistant.

The first employee is planning a trip to Dubai next month. She wants to know how much leave she has, how long she should take off, what to see there, and whether next month is a good time to go.

The assistant answers all of it. It checks her leave balance and finds nineteen and a half days. It suggests taking five to seven days off. It lists a few things to do in Dubai. It adds that July is hot, but flights are cheaper then.

Some of that is not strictly HR. Travel tips are not leave policy. The system allows it anyway, because a travel suggestion sitting next to a leave question is useful rather than dangerous.

The second employee asks something else. He has heard about a war and wants to know what is happening.

The assistant says no.

Same system. Same group of employees. One question gets a full answer that goes a little outside HR. The other gets turned down.

The difference is not what the assistant knows. It is what the assistant is allowed to do.

That line has to be drawn somewhere, and in HR it is harder to draw than almost anywhere else. The rest of this article explains where HONO put the line, why it sits there, and what happened the two times it was in the wrong place.

Why HR is the hardest place to draw the line

A general-purpose chatbot has an easier job than people think. It sits inside a wide field and only has to refuse things that are clearly off-topic or clearly unsafe. The fence around it is high, but there is a lot of room inside.

An HR assistant has the opposite problem.

The field is small. It covers HR data and HR workflows, and nothing else. But almost everything inside that small field is sensitive in some way. Salary. Reasons for taking leave. Medical certificates uploaded for sick leave. Performance ratings. Manager comments. Termination paperwork. Reasons someone left the company.

So the fence is not the hard part. What sits inside the fence is the hard part.

Why “be helpful” is not a safe default in HR

Most AI assistants are built around a simple instruction: be helpful. In a customer support tool, that works well. In HR, it causes problems that do not exist anywhere else.

Three examples show why.

An assistant that happily answers “who’s on sick leave today?” is not just sharing an attendance record. It is letting someone work out who is unwell. That is medical information arriving through the back door.

An assistant that agrees to “rank my team by age” is taking part in a discriminatory request. It does not matter that the data is technically available to the person asking. The act of producing that list is the problem.

An assistant that drafts “a warning letter for Priya” on request is doing real damage if Priya raised a harassment complaint in the same chat two messages earlier. The assistant has no idea it just helped with retaliation.

None of these questions look dangerous. Each one sounds like a normal request from a normal manager on a normal day. That is exactly what makes them hard.

Guardrails are not a final layer

Because of this, HONO does not treat guardrails as a policy filter added at the end of the build.

They are the first thing a question meets. They run before the system decides whether to look anything up, and they decide whether the rest of the system runs at all.

That order matters. A guardrail that checks the answer after it has been produced is already too late, because the data has been fetched and the reasoning has happened. A guardrail that checks the question first can stop the process before anything sensitive is touched.

The three gates every question passes through

Before HONO’s assistant answers anything, the question travels through three checks in order.

Each check asks something different. And each one refuses in different words, because the reason for saying no is different every time.

• Gate 1 is scope. Is this an HR question at all? Leave, attendance, payroll, performance, recruitment, separation, expenses, policies. If the question falls outside that list, it is out of scope. Not because the model cannot answer it, but because it should not.
• Gate 2 is authority. If it is an HR question, is this person allowed to ask it? Asking about yourself is always fine. Asking about someone who reports to you is fine once the system has checked that they really do report to you. Asking about anyone else is refused, no matter what relationship the person claims to have.
• Gate 3 is policy. The question is about HR. The person is allowed to ask. Will HONO answer anyway? This is where discrimination checks, confidentiality before announcements, refusal to draft coercive content, and resistance to bulk data requests all live.

The third gate matters most, and it is the one most teams underestimate. Its refusals look like the system does not have the information. In truth, the system has it and is choosing not to use it.

After the three gates, a question ends up on one of three paths: it gets answered, it gets refused, or it gets passed to a human being. Every one of those decisions is written to an audit log.

Some guardrails watch the conversation, not the question

One point is easy to miss and worth stating on its own.

A single refusal is a decision. Twenty refusals to the same employee about the same coworker is something else. That is a signal about behaviour, and it triggers a guardrail of its own, one that no single question would ever set off.

More on that later in the article.

Gate 1: Is this even an HR question?

The scope gate is the easiest of the three to build. It is also the easiest to get wrong.

It is easy to build because the HR vocabulary has edges. Leave. Attendance. Payroll. Performance. Hiring. Separation. Policies. Expenses. If a question sits outside that list, it is outside the assistant’s job.

It is easy to get wrong because the urge to be helpful keeps trying to stretch it.

Everywhere else in the product, HONO’s assistant is designed to feel like a warm, capable colleague. And a warm, capable colleague would answer a question about the news, or the weather, or last night’s match. That is what colleagues do.

So the instinct that makes the assistant feel human pulls directly against the instinct that keeps it in its lane. That tension does not go away. It has to be handled.

The answer is to refuse warmly

HONO’s assistant does not lecture when a question falls outside HR. It does not read out a list of banned topics. It does not tell the employee they have broken a rule.

It simply points back to what it can do.

The redirect is the answer. The employee is not told off. They are told what to ask next.

Two things the scope gate does before it refuses

It searches the knowledge base first. Some questions look out of scope but are not. “What’s the project plan for the Riyadh rollout?” or “What’s our hybrid-work policy?” may be answered by documents the customer has uploaded into their own knowledge base. So the gate looks there before it refuses on scope grounds.

Refusing first would have made the product worse. It would also have taught employees that the assistant knows less than it really does, and once people believe that, they stop asking.

The fence moves per customer. A customer can widen the scope of their own deployment. They might add a weather tool, or a travel-policy tool, or a currency converter. When they do, the gate respects it and the assistant is allowed to use them.

So this is not one fence around every deployment. It is a fence each customer’s admin can adjust.

Gate 2: Who is allowed to ask about whom?

The second gate decides whether the person asking has any business asking. HONO’s assistant recognises exactly three categories.

• Yourself. “My profile.” “My leave balance.” “My payslip.” These are always allowed. The tool runs against the asker’s own record and no checking is needed.
• Your direct reportees. “Show me Ravi’s attendance.” “Approve Priya’s leave request.” Here the system does not take the manager’s word for it. It looks up the asker’s list of reportees first, confirms the named person is actually on it, and only then goes ahead.
• Everyone else. Refused.

The “Priya is my friend” trap

That third category includes a case worth calling out on its own.

An employee asks: “Priya is my friend, can you tell me when she’s back from leave?”

It sounds harmless. It probably is harmless most of the time. The system still refuses.

The reason is simple. The relationship a person claims is not the relationship the system acts on. The only relationship that counts is the one recorded in the HRMS.

A friend is not a reportee.

Why a vague refusal was a bad refusal

Early on, when someone asked about a person outside their team, the assistant gave a flat answer: it did not have access to that.

That turned out to be a poor way to say no. Employees could not tell whether the system was broken, whether they had typed the name wrong, or whether the answer was simply no. So they asked again. And again.

The refusal was rewritten to be specific. It now names the person who was asked about. It names their department. It lists the first few employees the asker is allowed to see. And it points them to HR for anything beyond that.

The employee still does not get the answer. But they understand why, and they know where to go next.

Bulk data requests stop here too

The authority gate is also where HONO draws a hard line on bulk personal data.

“Export everyone’s phone numbers.” “List all salaries.” “Give me a spreadsheet of every reportee’s home address.”

These are refused in chat. Even when the person asking is an administrator. Even when the system is confident they have the rights.

The reason is not access. It is intent and paper trail. Bulk exports of personal data belong in the admin reports section, where approvals apply and the request is on record. A conversation leaves no such record, so a conversation is the wrong place for it.

Gate 3: Should we answer at all?

This is the gate that matters most, and the one most teams pay least attention to.

By the time a question arrives here, it has already cleared the first two checks. It is an HR question. The person is allowed to ask it. The only thing left to decide is whether the request itself is something HONO should help with.

Four kinds of requests get refused here. Each one exists because of a specific harm the system will not take part in.

Discrimination

A manager asks the assistant to rank their team by age.

The data is there. Date of birth sits in every employee record. The authority is there too, because these are the manager’s own reportees. Two gates have already passed.

The assistant refuses anyway, and the wording is the point.

Confidentiality before an announcement

Is John being fired? Did Priya get promoted? Who is on the layoff list? What is Rahul’s new salary?

The data often exists, and the person asking often has access to it. The assistant still says no until the person whose situation is changing has been told first.

The rule protects the employee being discussed, not the one asking. It covers termination, resignation, layoff, promotion, transfer, salary revision and performance improvement plans.

Letters written in anger

The assistant will draft a polite follow up to a leave request, a policy reminder for a team, or a summary of a candidate’s interview history.

It will not draft a warning letter for someone the asker has no authority over, a performance improvement plan aimed at an employee who raised a harassment complaint two messages earlier, or a termination memo written mid dispute.

A refusal that hands the problem to a human is different from one that shuts the door. The person still gets help. They just do not get it from the assistant.

When refusing would be the wrong answer

Someone types that they cannot take it anymore, or that they are burnt out, or that they are being bullied and HR is not listening.

The assistant does not refuse these. Refusing here could genuinely hurt someone, so this is the one place in the design where the rules point the other way.

It is also the only place where the model is allowed to step outside its normal working vocabulary and answer the person rather than the task.

The words of a refusal are part of the design

One idea runs through everything above, and it is worth stating on its own.

The exact words a system uses to say no are not a writing detail. They are a design decision, because they tell the person why the answer is no.

Take the most common phrasing: “I don’t have access to that.”

That sentence means something specific. It means the rule is about availability. It implies that if the data were there, the assistant would have helped.

Sometimes that is true. When someone asks about an employee outside their team, the data genuinely is not available to them, and the sentence is honest.

Sometimes it is false. When someone asks for a ranking by age, the data is right there. The refusal has nothing to do with access. Claiming otherwise is simply dishonest.

Each kind of refusal has its own family of words:

• “That’s not the kind of comparison I help with” is the language of principle.
• “I’ve flagged this for HR” is the language of escalation.
• “What can I help you with on leave, attendance, or payroll?” is the language of scope.

Using the wrong family is the difference between a refusal that builds trust and one that quietly wears it away.

The two times the guardrails got it wrong

Systems like this fail in two directions. HONO has hit both.

The refusal that should never have happened

Early on, an employee asked when their own birthday was. The assistant said it did not have access to their personal information.

Their own profile. Their own birthday. One step away in the same record that held their name and job title.

• What went wrong: order, not policy. The rules saw a personal data question and refused before the self service path ever ran.
• The fix: any question containing my, mine or self now calls the profile tool first, and never refuses without looking.
• The lesson: a safe default is not the same as a correct one. A system that says no to its own users about their own data is not careful. It is broken.

The pattern no single question revealed

An employee asks if Anita is in office. Then the same the next day. Then her leave, her usual hours, her next holiday booking.

Every question is fine alone, so none of them get refused. The pattern is another matter.

• What it looks like: one person, asked about repeatedly, by the same colleague, over days, with no working relationship anywhere in the org chart.
• What it actually is: not a workflow. Surveillance shaped like a workflow.
• The fix: a layer above the per question checks that watches who asks what about whom over time, and flags repeated interest in someone outside the asker’s working relationship.
• What the user sees: nothing. They still get answered. An administrator quietly gets a note.

The audit layer

Every decision the assistant makes gets written to a log. Every answer, every refusal, every escalation, every security flag.

That log serves three groups:

• Administrators get a record of what the assistant did and did not answer, for any user, over any period.
• Security teams get tagged records of jailbreak attempts, prompt injection and bulk data probes, surfaced for review without being shown to the user.
• The system itself gets a feedback signal over time on which refusals turned out to be wrong, which escalations were justified, and which patterns deserve a new guardrail.

The log also removes personal data from its own records. Emails, phone numbers, salary figures and national ID numbers are stripped before anything is written, so the audit trail never becomes a second copy of the data the assistant was being careful with.

The guardrails apply to the guardrails.

What HONO still does not let the model do

Three things are fenced off completely, even from the parts of the system that work best. Naming them matters, because the team needs to be able to see where the line sits.

• Professional judgement. Whether a termination is legal, what medical leave someone should take, how to plan tax. The assistant can explain a process. It cannot give the opinion. These go to HR, a labour lawyer or a tax adviser.
• Coercive letters without verified authority. Warning letters, performance improvement plans and termination notes are drafted only when the asker has confirmed authority over that person, and only when the request is not sitting directly after a complaint from them in the same conversation. The model can write a good plan. It cannot decide that now is the moment for one.
• Decisions about groups. Identify the bottom ten percent. Rank people for termination. Choose who goes on a plan. Per person decisions on a reportee’s file are fine. Decisions about a list of people, dressed up as a question, are not.

The question that gets harder as models improve

The line between answer, refuse and escalate is not fixed. The interesting question is where it moves next.

Today, distress signals go to HR. Today, coercive drafting needs verified authority. Today, confidentiality before an announcement is absolute.

As models get better, the pull to widen that line grows. Better refusals could justify answering things that are currently escalated. Better memory across turns could turn per question rules into per conversation ones.

But the honest answer may run the other way. A more capable model can do more damage if the guardrails fail. A weak model fails loudly. A strong one fails quietly, and sounds confident while doing it. The rules around it may need to get stricter, not looser, as the model underneath gets stronger.

A system that says no carefully is more trustworthy than one that says yes confidently.

Guardrails on an HR assistant are not a layer painted over the model. They are the architecture. Three gates, four kinds of refusal, a pattern layer above them, an audit log beneath, and the discipline to use the right words for the right kind of no.

The model is the easy part. The gates decide whether it gets to be useful at all.

See HONO in action

If you are choosing an HR assistant, ask the vendor how it refuses, not just what it answers.

Request a Demo