There are different problems with HTTP vs. HTTPS and being on an internal network should mitigate some.

• no strong server identification: not important on a internal network, it is unlikely that a fake server could exist in the internal network
• confidentiality of responses to requests made by authorized employees: it depends whether all authorized access all come from same office (only admins or co-workers with equivelent access permissions should be able to spy(*)) or if any manager can do requests. In the latter case risk of interception of confidential data are important but the (internal) attacker cannot know in advance what information it will gain.
• credential protection: if even the authentication procedure uses plain HTTP, the problem is much more serious. In that case, an attacker could get credentials and be able to issue requests (including modifications) on behalf of a legitimate user: integrity is no longer guaranteed not speaking of confidentiality

Of course, if it is a readonly server, and if confidentiality is not really a concern, HTTP can be used. But as soon as we speak of HR, confidentiality should immediately raise to a medium to high level.

(*) in common corporate networks, the usage of switches and proxys only allows to spy exchange on same subnet, except for network admins that can see all unencrypted traffic of their domain.

There are different problems with HTTP vs. HTTPS and being on an internal network should mitigate some.

• no strong server identification: not important on a internal network, it is unlikely that a fake server could exist in the internal network. Normally such a MITM attack would require administrative privileges, and in a corporate organization, you already have to trust the admins because they manage all network equipments and client machines.
• confidentiality of responses to requests made by authorized employees: it depends whether all authorized access all come from same office (only admins or co-workers with equivelent access permissions should be able to spy(*)) or if any manager can do requests. In the latter case risk of interception of confidential data are important but the (internal) attacker cannot know in advance what information it will gain.
• credential protection: if even the authentication procedure uses plain HTTP, the problem is much more serious. In that case, an attacker could get credentials and be able to issue requests (including modifications) on behalf of a legitimate user: integrity is no longer guaranteed not speaking of confidentiality

Of course, if it is a readonly server, and if confidentiality is not really a concern, HTTP can be used. But as soon as we speak of HR, confidentiality should immediately raise to a medium to high level.

(*) in common corporate networks, the usage of switches and proxys only allows to spy exchange on same subnet, except for network admins that can see all unencrypted traffic of their domain.