AI-assisted job description writing without sending req details to a third party
A job requisition starts as a set of notes from a hiring manager: the role's actual responsibilities, the team it sits in, a rough salary band, why headcount got approved in the first place. Turning that into a job description that reads well and doesn't bury the requirements in filler is exactly the kind of writing task an LLM handles well. It's also a task that touches unannounced headcount plans and internal salary bands, which is worth keeping off a third party's servers before the role is even public.
Not legal advice. This post describes an infrastructure setup, not employment law guidance. Job description requirements, including pay transparency and non-discrimination rules, vary by jurisdiction. Check with your own HR and legal counsel before publishing.
Why req details don't belong on a third-party API
A draft job req is a leading indicator of a company's plans: what team is growing, what role is opening up, sometimes what a competitor's talent might be poached for, and almost always a salary band that hasn't been made public yet. Feeding that into a general-purpose AI product means a third party has a copy of information a company would rather not have circulating before the role posts, subject to whatever retention policy applies to that vendor's plan. It's a smaller-stakes version of the same problem covered in private AI for internal communications: pre-announcement information benefits from staying inside infrastructure the company actually controls.
Running the model on a dedicated instance means the hiring manager's notes, the salary band, and every draft stay on hardware the company operates, with nothing sent externally until the company itself decides to publish the finished posting.
What it's actually good for
The main use is turning rough, unstructured notes into a clean draft: taking a hiring manager's bullet points and a template the company already uses, and producing a first draft with a consistent structure, tone, and length. A model is also useful for consistency across a batch of postings, checking whether the same seniority level is described with comparable language across different team's reqs, which matters for both candidate experience and, in some jurisdictions, pay transparency compliance.
A second use is generating variations for different channels: a longer version for the careers page, a shorter one for a job board with a character limit, without a recruiter rewriting the same content three times by hand.
Where it stops being a drop-in replacement
A drafted job description still needs review by someone who understands the legal requirements that apply to the posting: pay transparency laws that require a disclosed salary range in some jurisdictions, language that could read as discriminatory even unintentionally, and internal consistency with how the company levels and titles roles. An LLM has no accountability for getting any of that wrong and no reliable way to know which jurisdiction's rules apply to a given posting unless it's told explicitly and correctly. HR review before publishing is not optional, and it's the step that actually determines whether the posting is compliant, not the drafting step.
It's also worth being direct about a known failure mode: language models trained on a wide mix of internet job postings can reproduce subtly gendered or otherwise skewed phrasing patterns from that training data unless a human reviewer is specifically checking for it. Treat the draft as a draft, and have someone read it for that specifically before it goes out.
A concrete example
A company's engineering director sends a recruiter a few rough paragraphs about a senior backend role: what the team owns, the tech stack, why the seat opened up. The recruiter runs it through a prompt template that follows the company's standard job-description format and produces a clean draft in the company's usual voice. The recruiter reviews it, adjusts a few lines, checks the salary range against the internal band and the jurisdiction's disclosure rules, and posts it. The unannounced headcount plan and the salary band it started from never left the company's own systems.
Where the hardware fits
This is a light workload: short prompts, short outputs, no large context requirement. A single DGX Spark handles a company's full hiring pipeline worth of drafting with room to spare, and at $0.79/hour on-demand it's cheap enough to run continuously through a hiring push without the cost becoming a factor. See pricing for the reserved rate if the Spark also serves other internal workflows between hiring cycles.