AI server for HR and recruiting: AI Act high-risk uses, GDPR and the hardware behind them

What an AI server does for an HR department

An AI server for HR runs the language and retrieval models of the personnel department on premises, on hardware the company controls, so applications, personnel files and HR questions stay inside the company's own access rules. For most companies a server with two NVIDIA RTX PRO 6000 Blackwell Server Edition cards carries the usual HR workloads; the larger question is which of them the EU AI Act treats as high-risk, and what that changes in logging, oversight and data separation.

Typical tasks for such a local LLM are an assistant that answers employees' questions about policies, leave and benefits from the HR handbook, drafts of job advertisements and letters, extraction of applications into a fixed structure and search over a pool of candidates. We wrote this for the HR director who has to decide which AI uses to start, and for the IT team that builds the platform. The legal part is general information on EU law as of October 2026, not legal advice; national labour and data-protection rules can add requirements, and your data-protection officer and legal counsel confirm the assessment for your company.

Which HR uses the AI Act lists as high-risk

Article 6(2) makes the AI systems listed in Annex III high-risk, and point 4 of the annex covers employment. We read it on the Commission's AI Act Service Desk on 24 October 2026, in the consolidated text as at 27 July 2026. Point 4(a) lists systems "intended to be used for the recruitment or selection of natural persons, in particular to place targeted job advertisements, to analyse and filter job applications, and to evaluate candidates". Point 4(b) lists systems used to make decisions affecting terms of work-related relationships, promotion or termination, "to allocate tasks based on individual behaviour or personal traits or characteristics or to monitor and evaluate the performance and behaviour of persons in such relationships".

Regulation (EU) 2024/1689, Articles 5(1)(f), 6(2) and 6(3), 26 and 113 and Annex III, point 4, on the Commission's AI Act Service Desk (consolidated text as at 27 July 2026), read 24 October 2026. The assignment of uses to rows is our reading of the listed purposes, not a legal assessment.

The dates come from Article 113 as amended by the Digital Omnibus on AI: Chapters I and II, which include the prohibitions, have applied since 2 February 2025, and the rules for systems that are high-risk under Article 6(2) and Annex III apply from 2 December 2027. Article 5(1)(f) prohibits AI systems "to infer emotions of a natural person in the areas of workplace and education institutions", except for medical or safety reasons, so a video-interview tool that scores a candidate's emotions is out of scope for any configuration.

Article 6(3) lets an Annex III system escape the high-risk class where it "does not pose a significant risk of harm", for example when it performs "a narrow procedural task" or "a preparatory task to an assessment". The same paragraph closes that door for profiling: an Annex III system "shall always be considered to be high-risk where the AI system performs profiling of natural persons". A tool that ranks applicants by a score derived from their CVs is hard to fit into the exemption. Our article on the EU AI Act for companies using LLMs covers the timeline, the provider and deployer roles and when a general assistant turns into a high-risk system because a department changes its purpose.

What the rules change in the platform

Article 26 sets the deployer duties for high-risk systems, and an employer that runs a recruiting tool is the deployer. Several of them land in the IT design.

• Human oversight. Article 26(2) assigns oversight "to natural persons who have the necessary competence, training and authority". In the platform that means a review step in the recruiting workflow before any rejection, done by named recruiters, with their decisions recorded.
• Logs. Article 26(6) asks deployers to keep the logs the system generates automatically "for a period appropriate to the intended purpose", "of at least six months", unless other Union or national law, in particular data-protection law, provides otherwise. Prompts, retrieved passages, outputs, model version and reviewer actions go into a log store with its own retention and access rules.
• Information. Before a high-risk system is put into service or used at the workplace, Article 26(7) requires employers to inform "workers' representatives and the affected workers". Article 26(11) requires deployers of Annex III systems that make or assist decisions about people to inform those people, which in recruiting includes the candidates.
• Use as instructed and monitoring. Article 26(1) and (5) tie the use to the provider's instructions and ask for monitoring and a way to suspend the system. A pinned model version and a change log on the server make that traceable.

Where a works council or another body of workers' representatives exists, plan the information or consultation step into the project before the pilot. National labour law can add consultation or co-determination rights beyond Article 26(7); this article does not describe them, and your legal counsel confirms what applies.

The GDPR applies to every HR use, high-risk or not. Article 22(1) gives the data subject "the right not to be subject to a decision based solely on automated processing, including profiling", where it produces legal or similarly significant effects; Article 22(3) asks for at least "the right to obtain human intervention", to express a point of view and to contest the decision where an exception applies. A rejection that software sends without a person looking at the application can fall under that article. Recital 155 adds that "Member State law or collective agreements, including 'works agreements', may provide for specific rules" on processing employees' personal data, so a works agreement can set conditions for the platform. Our guide to a DPIA for an internal LLM lists the inputs IT supplies for the impact assessment, which an HR use with scoring will often need.

We supply the server and, through our Private AI/ML service, set up the model, the retrieval and the query log with retention you choose; tell us which HR uses you plan and where the data comes from, and our team replies with a configuration.

Three ways to run HR workloads

The options follow the reference configurations on our AI servers page and NVIDIA's guide for certified systems: two processors, at least six cores per GPU and system memory of twice the GPU memory. The language model in the examples is gpt-oss-120b, released under Apache 2.0, whose 60.8 GiB checkpoint fits one 96 GB card.

Reference configurations on our AI servers page; requests by our users-per-card rule with gpt-oss-120b and a 16-bit cache; the CV batch of 5,000 applications by our arithmetic from MLPerf® v6.1 entry 6.1-0050 at half the published rate (see the sizing section); power by our estimate with the cards at 600 W, processors and 15 per cent for the rest of the server.

An HR share of the company's AI server. Many companies already run an assistant for all staff. Low-risk HR uses, such as the policy assistant and drafting, can run there as a separate tenant: an index that holds only HR documents, an access role that only HR staff and the assistant's service account carry, and a log stream with HR's own retention. On a four- or eight-card server one card can be reserved for HR, or one of the four 24 GB MIG instances of an RTX PRO 6000 for HR's retrieval models. MIG gives each instance its own memory and fault isolation, which separates workloads in hardware; it does not add capacity for a model as large as gpt-oss-120b, which needs a whole card.

Two cards for HR alone. The entry server has two RTX PRO 6000 Server Edition, two AMD EPYC processors, 384 GB of DDR5 ECC and two NVMe drives. Card 1 runs gpt-oss-120b for the policy assistant, drafting and the extraction of applications into JSON. Card 2 is split by MIG into four instances for the embedding model and reranker, an OCR model for scanned certificates, and two instances for staging and for evaluating a recruiting model before it goes live. A separate server makes sense where the high-risk uses start: administrators, backups and the log store are then HR's alone, and the general company platform never holds application data.

Four cards for a large employer or a shared HR service. The inference node with 768 GB and four NVMe drives runs the assistant as one copy split over cards 1 and 2 with tensor parallelism, which leaves 105.3 GiB of cache and 187 requests in flight at 16K. Card 3 carries batch jobs such as application extraction during a graduate campaign, card 4 the retrieval models in MIG instances. This size suits an HR shared-service centre that answers employees in several countries.

The RTX PRO 6000 Max-Q is the workstation card, a 300 W blower card; in a rack it belongs only in a chassis whose maker lists it, and for continuous operation we recommend the Server Edition.

Sizing the HR workloads

HR workloads are small for these cards. The policy assistant is a chat load and is sized by requests in flight at the busiest hour. By our users-per-card rule, which takes 90 per cent of the 95.6 GiB the driver reports, less 3 GiB per card and less the weights, gpt-oss-120b leaves 22.2 GiB of cache on one card. At a declared context of 16,384 tokens a request takes 0.5625 GiB of 16-bit cache, so one card holds 39 requests in flight and a tensor-parallel pair 187. With the example value of our guide to a private ChatGPT server by company size, about 4 requests in flight per 100 employees at the peak, one card covers about 975 employees and a pair about 4,675, if staff use the HR assistant as often as a general one. Your gateway log after a pilot replaces the example value.

Applications arrive in waves. Take a campaign of 5,000 applications whose CVs and cover letters are turned into a JSON record of about 300 tokens each with vLLM's structured outputs: 1.5 million output tokens. In MLPerf® Inference v6.1, an HPE server with eight RTX PRO 6000 Server Edition cards produced 15,256 tokens per second on gpt-oss-120b in the offline scenario (entry 6.1-0050), 1,907 per card by our division. At that rate one card writes the records in about 13 minutes; with half the published rate as our planning margin, about 26 minutes. A CV is longer than the benchmark's prompts and reading it takes time on top, so time a sample of your own applications before you plan a campaign window.

MLPerf® Inference: Datacenter v6.1, closed division, available category, gpt-oss-120b, offline scenario, entry 6.1-0050 (HPE ProLiant Compute DL380a Gen12, eight RTX PRO 6000 Blackwell Server Edition), 15,256 tokens per second, retrieved from mlcommons.org on 24 October 2026, result verified by MLCommons Association; 1,907 per card is our division of the system result, not an MLPerf metric. Embedding rate of 144.3 chunks of 512 tokens per second for NVIDIA's 1B embedding model on an L40S from NVIDIA's NIM 1.14.0 performance page, as cited in our embedding guide. Example volumes are ours. The MLPerf name and logo are registered and unregistered trademarks of MLCommons Association in the United States and other countries. All rights reserved. Unauthorized use strictly prohibited. See www.mlcommons.org for more information.

A talent pool for semantic search is the retrieval side of recruiting. 50,000 CVs at four chunks of 512 tokens give 200,000 chunks, which NVIDIA's published rate for its 1B embedding model puts at about 23 minutes on one L40S by our arithmetic; NVIDIA publishes no rate for a MIG instance of an RTX PRO 6000, so time it there. Searching that pool to shortlist candidates is close to the filtering of applications in point 4(a), so treat the search index as part of the high-risk system once it is used that way. Our guide to embedding and reranker servers for RAG compares the retrieval models.

Throughput is rarely the reason to buy more cards for HR. Separation, a second server for failover and the evaluation of a candidate model next to the production one are the usual reasons.

Notes for the IT team

1. Separate the data. HR documents go into an index of their own, and every chunk carries the access list of its source, so retrieval filters before it ranks. A directory role grants access; the prompt cannot change it. Our guide to RAG on company data describes the filter.
2. Keep the connectors closed. Connectors to the applicant tracking system or performance reviews stay off until legal has classified the use, as our AI Act article recommends. Low-risk uses can start without them.
3. Applications carry injected text. A CV can hold white text on a white background or instructions in its metadata, written for an AI screening tool. Treat every application as untrusted input, extract into a fixed schema and keep the model away from actions, as our guide to prompt injection and LLM security explains.
4. Log for the record. Put an LLM gateway with keys and a query log in front of the engines. Log prompts, retrieved sources, outputs, model version and the reviewer's decision, keep them at least six months for a high-risk use and agree the retention with your data-protection officer.
5. Pin the model. Fix the model, version and settings, and run a new version through an evaluation set of anonymised past applications before it replaces the old one; our guide to LLM evaluation before model upgrades describes the set.
6. Train the users. Article 4 on AI literacy has applied to all AI systems since 2 February 2025; our guide to AI literacy training under Article 4 sets out training by role, recruiters included.
7. Network and versions. vLLM's --api-key protects only paths under /v1, /v2, /inference and /cohere, while routes such as /invocations and /metrics answer without the key (vLLM 0.32.0 security guide), so keep the engines on an internal network behind the gateway. Run vLLM 0.31.0 or later, the NVIDIA Container Toolkit at 1.17.8 or later and a driver NVIDIA lists as fixed in its bulletin of 30 September 2026.

Our Private AI/ML service builds the HR tenant or the HR server with these controls; describe the first HR use you would start with, and we propose a pilot and the hardware for it.

Power and room

By our estimate, the two-card server draws about 1.8 kW at the wall with two EPYC 9135 processors and fits one 230 V 16 A feed, which carries 2.94 kW at 80 per cent. The four-card server draws about 3.4 kW with the cards at 600 W and needs 32 A or three-phase, or about 2.7 kW with the cards capped at 450 W. The measurement on the delivered system confirms these figures. Both belong in a server room or a data centre; our guide to GPU server power on 16 A, 32 A and three-phase feeds works through the feeds. Without a server room of your own, our Private AI/ML service runs the platform on dedicated hardware in a Tier-3 data centre in Lithuania, inside the EU.

What we supply

You can buy this system from us: our team sizes the configuration to your workload and budget and replies within one business day. We build the servers to order with two, four or eight RTX PRO 6000 Server Edition cards, assembled and tested before delivery, delivered anywhere in the EU on one EU contract and invoice, with manufacturer warranty on every component handled through us; quantities and lead time are confirmed in writing with the quote. Our Private AI/ML service, built by our engineering partner Vixen.UNO, deploys the models, the HR index, the access rules and the query log. On the AI Act we deliver the technical part; the legal classification stays with your legal counsel. Our guide to buying a GPU server for LLMs lists every configuration.

FAQ