Pipeline
How Do You Write an AI-Skills Requirement That Isn't Legally Vague?
An AI-skills requirement in a job posting holds up when it names three things: the occupational task the assistant is used on, the point where a person has to override the model, and the step in your process where a candidate proves it. "Proficient with AI" isn't that; it's a qualification standard, and if it screens anyone out you have to show it's job related and consistent with business necessity. The posting is evidence of what you called essential. If no task in the role passes that test, require none.
The takeWriting the line this way does something before it ever screens anybody: it makes the hiring team say out loud who catches a plausible wrong answer today. Often the honest answer is nobody, and the requirement is really a request for one new person to absorb a review step the company quietly deleted. That is a missing control, not a missing skill. I suspect the postings that still read well in two years will be the ones a manager could have written from memory, because they knew exactly where the work goes wrong.
Where Olive fits
Open a role and see what the work shows
Olive assesses what a requirement line can only assert: a 40-to-60-minute assignment written for the occupation, done with an AI assistant, returned as six separately evidenced findings a human reviewer wrote by hand, with the candidate granted the same report. It is priced per attempt rather than per seat and ten attempts a month are free, so the bar you just wrote can be checked against real candidates instead of restated in the next posting.
Rank your shortlistWhat makes an AI-skills requirement legally vague?
Naming a trait or a tool instead of a work behavior. "Proficient with AI", "AI-first mindset", "strong prompt engineering skills": none of them describes something the job does, so nobody can say what would satisfy them or what would fail them. That is the vagueness, and it is the same defect whether the reader is a candidate, an interviewer, or a lawyer reading the posting two years later.
The legal half is specific. A requirement in a posting is a qualification standard, and under the ADA regulations a standard that screens out or tends to screen out an individual with a disability is unlawful unless it is shown to be job related for the position in question and consistent with business necessity 1. Separately, a written job description prepared before advertising or interviewing applicants is listed in the same regulations as evidence of whether a function is essential 2. The sentence is not advertising copy. It is a document about the job, produced by you, before any dispute existed.
The Uniform Guidelines add the drafting rule almost verbatim. A job analysis should focus on the work behaviors and the tasks associated with them, and where a behavior is not observable it should identify the aspects of it that can be observed and the resulting work products 3. "Proficient with AI" has no observable aspect and no work product. "Ties every figure in a draft memo back to the filing it came from" has both, and the second one took no longer to write.
The screening half costs you sooner. A requirement nobody can define is a requirement every applicant can claim, so it filters nothing at the top of the funnel and gives the interviewer nothing to ask about at the bottom. That is why checking an AI-proficiency claim on a resume is such awkward work in most processes: the claim was invited by a line that never said what it meant.
Write the requirement in three parts
Task, judgment, proof. Name the occupational task the assistant will be used on, name the point in that task where a person has to override or refuse what the model produced, and say how a candidate demonstrates it in your process. Three clauses, one sentence each, and every one of them is checkable by someone who was not in the room when you wrote it.
- The task comes from the job, not from a tool vendor. O*NET publishes a task list for every SOC code, and the occupation's own statements are a starting column nobody in your hiring meeting wrote. Pick the two or three tasks where the assistant will actually be used, and quote the work rather than the software.
- The judgment is the part a model gets wrong confidently. Every exposed task has a moment where the output is plausible and incorrect: a figure with no source, a citation that does not exist, a code the documentation will not support. That moment is the requirement, and it is also what an interview round can be built around.
- The proof is a step in your loop, named. "Assessed in the second round on a short exercise" turns the requirement into something a candidate can prepare for and an interviewer can grade. A requirement with no named proof is the one that later reads as a pretext.
Then delete the rest. Tool names date within a release cycle and turn a capability requirement into a brand preference. Years of experience with a technology most people met eighteen months ago is a number nobody can defend. And adjectives (savvy, fluent, forward-thinking) name an impression rather than work; the moment one of them decides who advances, it is a selection procedure 12, and a selection procedure has to be job related and consistent with business necessity 4.
The finished line is longer than what it replaces, and that is the trade. Two sentences an interviewer, a candidate and a lawyer all read the same way beat four words each of them reads differently. If you are also setting the bar the requirement points at, write the bar first: the requirement is a summary of it, not a substitute for it.
Rewrite the requirement for six occupations
Same three parts, six different jobs. Each row below takes a task statement from the occupation's own published task list, finds the moment in it where a confident wrong answer costs something, and writes the requirement around that moment. Nothing in the second column transfers to another row, which is the point: a requirement that fits six occupations fits none of them.
| Job title | Vague posting line | Defensible version |
|---|---|---|
| Software developer, SOC 15-1252 6 | "Experience with AI coding tools required." | Uses an AI assistant when modifying existing software to correct errors or improve performance, and can show a change where the generated patch was narrowed or rejected because of a constraint the assistant had not been given. Assessed in the technical round, on a repository the candidate has not seen. |
| Financial analyst, SOC 13-2051 7 | "AI-savvy analyst wanted." | Uses an assistant on first-pass analysis of company financials, and ties every figure that reaches a recommendation back to the filing or dataset it came from. Assessed by asking the candidate to source three numbers in a memo they drafted with an assistant. |
| Market research analyst, SOC 13-1161 8 | "Strong prompt engineering skills." | Uses an assistant to draft reports of findings, and opens the underlying survey or study before a statistic goes into anything a customer reads. Assessed with a source packet in which two documents do not support the summary written from them. |
| Paralegal, SOC 23-2011 9 | "Comfortable with legal AI." | Uses AI research tools when investigating the facts and law of a case, and confirms every authority in the primary source before the work reaches an attorney. Assessed with a short research memo containing one citation that does not exist. |
| Medical records specialist, SOC 29-2072 10 | "AI experience a plus." | Uses coding-assistance software on the coding queue, and consults the physician instead of accepting a suggested code when the documentation is missing, conflicting or unclear. Assessed with five records, two of which will not support the code the software suggests. |
| Logistician, SOC 13-1081 11 | "AI fluency required." | Uses an assistant when reviewing subcontractor proposals and when developing proposals that include documentation for estimates, and recomputes landed cost by hand when quotes are written on different terms. Assessed with three quotes an assistant has already summarized into one misleading comparison. |
Two things travel across the rows and nothing else does. The shape is constant (a task, a moment of judgment inside it, a named proof), and the object is never constant, because a plausible wrong answer in a coding queue looks nothing like a plausible wrong answer in a code review. That is also why one company-wide AI requirement pasted into every requisition fails both tests at once: unassessable in the roles that need it, unjustifiable in the roles that do not.
If your requisitions already carry a generic line, the cheaper repair is to rewrite the AI requirement one requisition at a time rather than to standardize a new generic line across all of them.
When is prompt engineering a real requirement?
When the occupation's published tasks include work the assistant will do end to end, and someone downstream pays for a plausible wrong answer. That describes an analyst drafting a memo and a developer modifying a service. It does not describe a role where the exposed work is a status email. Requiring it there costs you applicants who could do the work, and you would still have to defend the screen it produced 1.
Three questions settle it, in this order:
1. Does the assistant do this task, or help with it? Help is a tool rollout. A first draft that could ship if nobody checked it is a capability requirement. 2. How often does that task run? Weekly is a requirement. Twice a year is a checklist and a colleague. 3. Who catches a plausible wrong answer today? If the honest answer is the client, the regulator or the board, the requirement is real. If the honest answer is the next reviewer in the workflow, it is a preference.
Notice what the three questions do not ask: whether the candidate uses a lot of AI, which model they prefer, or how a prompt was phrased. Prompt syntax is the least durable thing in the room, since it moves with each model release, and a requirement written against it expires before the first hire finishes ramping. The judgment persists, which is why the defensible version of every row above names an act rather than a technique.
The same triage tells you which requisitions should carry no AI requirement at all. Working out which roles genuinely need AI skills before the postings go out is a shorter exercise than pulling the line back out of forty job descriptions afterwards, and it leaves a record of why each role was decided the way it was.
Check the requirement against the screen it creates
A requirement becomes a filter the moment someone puts it in the applicant tracking system, and that filter is a selection procedure whether or not you called it one, a term the Uniform Guidelines run through informal interviews and unscored application forms 12. Before the posting goes live, ask three things: what search string will enforce this, who does that string remove, and what in your process would tell you the removal was right.
The ADA answer to the second question is specific. Employers are expected to examine hiring technologies before use, and regularly while in use, to assess whether they screen out individuals with disabilities who can perform the essential functions with or without reasonable accommodation, and to grant a requested accommodation that would let someone meet a qualification standard, unless it would be an undue hardship 5. A keyword screen built out of your own requirement line is a hiring technology by that description. So the line needs a stated alternative path, and a named person who owns it.
Keep the working papers. The task list the requirement came from, the two or three tasks you selected, and the note on who catches a wrong answer today are the whole answer to "why was this required": an afternoon's work before the posting, and impossible to reconstruct honestly two years after it. Store them with the requisition rather than in a folder nobody can find.
Then accept the limit. A requirement, however carefully drafted, is a claim you are inviting; it is not evidence. "Opens the underlying study before a statistic goes into anything a customer reads" is now exactly what every applicant will say, which is the trade you took in exchange for a screen an interviewer can actually run. What closes that gap is a step where the act happens in front of someone: moving the real assessment ahead of the resume screen is one way, and it gets more attractive as applications per opening climb past what any human reader can absorb.
Common questions
Is "AI proficiency required" actually illegal?
No. A vague requirement is not unlawful in itself. It becomes a problem when it screens someone out and you are asked to show it is job related for the position in question and consistent with business necessity, which the ADA regulations require of any qualification standard that screens out an individual with a disability. The practical risk is not a statute; it is that nobody wrote down what the line meant, so the answer has to be assembled after the fact by people who were not there. Write it so the answer already exists.
Should the AI requirement sit under required or preferred?
Required only if the task is one the role exists to perform and a wrong answer is expensive. Everything else goes under preferred, or comes out. The heading matters more than it looks: a written job description prepared before you advertise is evidence of which functions are essential, so where a line sits is part of that record. A preferred line still needs a task and a proof. It just does not remove anyone from the pool on its own, which is the right treatment for a capability the job exercises occasionally.
Does an AI certificate satisfy a requirement written this way?
It does not, and that is the point of writing it this way. A certificate shows a course was completed, not that a person refused a plausible wrong answer in your kind of work. If a requirement can be satisfied by a credential, it was written as a credential requirement rather than a work requirement. Treat certificates as evidence of exposure, keep the assessment step, and keep vendor certification names out of the requirement line: the moment a specific one is required, you have narrowed the pool on something you cannot tie back to the task.
What if the role's AI work is new and there is no task list for it?
Write the requirement from the task the AI is being used on, which is not new. Published task lists already describe drafting, reconciling, coding, comparing and investigating, and those are the tasks an assistant is aimed at. What is new is who does the first pass and where the checking moved. Name that: the task, the moment the person takes it back, and the proof. If no task in the role passes the three-question test, the role has no AI requirement yet, and saying so in writing beats a placeholder line nobody can enforce.
Who should write the line: HR, the hiring manager, or legal?
The hiring manager supplies the task and the moment of judgment, because only they know who catches a wrong answer today. HR writes it into the three-part form and owns the record. Legal reads it once, against a single question: if this removed someone, could the removal be explained from the task list. That review takes minutes when the requirement names work, and turns into a debate when it names a trait, which is a useful early signal that the line is not finished.
References
- 1. 29 CFR 1630.10 - Qualification standards, tests, and other selection criteria ✓ ecfr.gov It is unlawful to use qualification standards, employment tests or other selection criteria that screen out or tend to screen out an individual with a disability unless the standard is shown to be job related for the position in question and consistent with business necessity. Accessed 24 August 2026.
- 2. 29 CFR 1630.2 - Definitions (essential functions) ✓ ecfr.gov Section 1630.2(n)(3)(ii) lists "written job descriptions prepared before advertising or interviewing applicants for the job" among the evidence of whether a particular function is essential, alongside the employer's judgment and the consequences of not requiring the function. Accessed 24 August 2026.
- 3. 29 CFR 1607.14 - Technical standards for validity studies (Uniform Guidelines on Employee Selection Procedures) ✓ ecfr.gov Paragraph (C)(2) requires a job analysis focused on work behaviors and the tasks associated with them, and states that where behaviors are not observable the analysis should identify the aspects that can be observed and the observed work products.
- 4. Employment Tests and Selection Procedures ✓ eeoc.gov A test or selection procedure that screens out a protected group on the basis of race, color, religion, sex or national origin must be job related for the position in question and consistent with business necessity. Accessed 24 August 2026.
- 5. Algorithms, Artificial Intelligence, and Disability Discrimination in Hiring ✓ ada.gov Employers should examine hiring technologies before use and regularly while in use to assess whether they screen out individuals with disabilities who can perform the essential functions with or without reasonable accommodation, and must provide requested accommodations that would let an applicant meet a qualification standard absent undue hardship.
- 6. 15-1252.00 - Software Developers ✓ onetonline.org Published task statements include modifying existing software to correct errors, adapt it to new hardware, or upgrade interfaces and improve performance. Accessed 24 August 2026.
- 7. 13-2051.00 - Financial and Investment Analysts ✓ onetonline.org Published task statements include informing investment decisions by analyzing financial information to forecast business, industry, or economic conditions. Accessed 24 August 2026.
- 8. 13-1161.00 - Market Research Analysts and Marketing Specialists ✓ onetonline.org Published task statements include preparing reports of findings, illustrating data graphically and translating complex findings into written text. Accessed 24 August 2026.
- 9. 23-2011.00 - Paralegals and Legal Assistants ✓ onetonline.org Published task statements include investigating facts and law of cases and searching pertinent sources, such as public records and internet sources, to determine causes of action and to prepare cases. Accessed 24 August 2026.
- 10. 29-2072.00 - Medical Records Specialists ✓ onetonline.org Published task statements include resolving or clarifying codes or diagnoses with conflicting, missing, or unclear information by consulting with doctors or others. Accessed 24 August 2026.
- 11. 13-1081.00 - Logisticians ✓ onetonline.org Published task statements include managing subcontractor activities, reviewing proposals, developing performance specifications, and serving as liaisons between subcontractors and organizations; and developing proposals that include documentation for estimates. Accessed 24 August 2026.
- 12. 29 CFR 1607.16 - Definitions (Uniform Guidelines on Employee Selection Procedures) ✓ ecfr.gov Paragraph Q defines a selection procedure as any measure, combination of measures, or procedure used as a basis for an employment decision, and says selection procedures "include the full range of assessment techniques from traditional paper and pencil tests, performance tests, training programs, or probationary periods and physical, educational, and work experience requirements through informal or casual interviews and unscored application forms." Accessed 24 August 2026.
12 sources, numbered by first appearance. Every one was opened and checked against the claim it carries. How Olive sources claims
General guidance for hiring teams. What works at one company and one volume may not transfer to yours.
Olive assesses how a person works with AI. It does not detect AI-written documents, and it never produces a score, a ranking, or a match percentage for a person. Candidates read the same report the employer reads.