Skip to content
Is there an AI for this?

Use case

Recruitment screening

Using AI in hiring — parsing CVs, matching candidates to requirements, ranking, structuring interview notes. Regulated as a high-risk application in the EU and constrained by anti-discrimination and automated-decision rules almost everywhere.

Source
Editorial ontology entry — no fetched document behind this page
Evidence
none on this page — it links to the pages that hold it
Category
People
Typical risk
high
Entry
editorial · reviewed 25 Aug 2026

01What this is

Recruitment screening covers CV parsing, requirement matching, shortlisting support and interview note structuring. The technical part is ordinary extraction and ranking; the legal part is not, because the output affects a person's access to employment.

A good deployment keeps a human decision-maker with real discretion, discloses AI use to candidates, documents the features used and explicitly excludes proxies for protected characteristics, tests for adverse impact before and during use, retains candidate data only as long as the process requires, and keeps records sufficient to explain any individual outcome.

Pitfalls: ranking models trained on past hiring that encode past bias; "assistive" scores that in practice decide; and vendor tools whose feature set cannot be described. Under the EU AI Act, employment and worker-management systems fall in the high-risk class, which brings documentation, logging, human-oversight and registration duties on top of data-protection law.

Typical data
candidate data, employee data, client documents
Solution classes it admits
Enterprise SaaS, Private cloud

02Deployment options

  • ASSESSMENT

    On a neutral reading of this use case, Self-hosted is a strong alternative, Private cloud is a strong alternative and Enterprise SaaS is conditional.

  • ASSESSMENT

    Read as a generic reading of this page, not a recommendation: no organisation, size, jurisdiction, budget or technical capability has been supplied, so wherever an option depends on one of those, it says "unknown". Ask your own question to get a verdict that accounts for them.

Private cloud

STRONG ALTERNATIVE

Managed model API or private model deployment in your cloud account

  • ASSESSMENT

    Two patterns fit inside one account in a region you name: call a managed foundation-model API such as Amazon Bedrock, Microsoft Foundry / Azure OpenAI, or Vertex AI; or deploy an open-weight model on GPU compute you control. Your application, retrieval layer, storage, identity and logs remain in your cloud boundary in both patterns.

  • ASSESSMENT

    The managed-API pattern can use closed-source frontier models without buying or operating GPUs. It is usually the fastest way to build a custom workflow, but prompts and retrieved context are processed by the managed service, so model availability, retention, abuse monitoring and regional routing must be checked for the exact feature and endpoint.

  • ASSESSMENT

    The private-model pattern gives more control over weights, serving and network paths, and can use managed endpoints or your own containers. It also makes your team responsible for capacity, patches, model upgrades, evaluation and failover.

  • ASSESSMENT

    The cloud provider becomes a data processor in either pattern: you need a DPA, a documented region, and an answer on cross-region routing and where support staff can access the environment from.

  • RECOMMENDATION

    Start with the managed-API pattern when the workflow is custom but model operations are not the source of competitive advantage; move to private model serving only if evaluation, volume, portability or the data boundary justifies the extra operations. Your stated technical capability is "unknown".

Self-hosted

STRONG ALTERNATIVE

Open-weight models on infrastructure you operate

  • ASSESSMENT

    Documents, queries and embeddings stay on machines you own, using an open-weight model whose licence you review. For a brief that involves confidential documents, special-category data and personal data, that removes a model-API vendor from the data path rather than governing that transfer by contract.

  • ASSESSMENT

    It costs you the operational work instead: a GPU server, Docker, Linux, backups and a patching routine. Your stated technical capability is "unknown", which is the attribute this option most depends on.

  • ASSESSMENT

    No processor agreement, subprocessor list or cross-border transfer assessment is needed for the model itself, because no third party processes the content.

  • RECOMMENDATION

    Recommended where local processing is preferred (you did not say so) and the content is sensitive (confidential documents, special-category data and personal data).

Enterprise SaaS

CONSIDER IF

Finished closed-source cloud product with enterprise controls

  • ASSESSMENT

    This is a complete vendor application, not a model API: examples include an enterprise assistant, coding copilot or document product with the workflow, interface, connectors and administration already built. It can use closed-source cloud models while requiring no model hosting or application engineering from your team.

  • RECOMMENDATION

    Choose it when the product already performs the actual workflow and its controls meet your requirements. Do not choose it only because its underlying model is strong: a finished SaaS product is less flexible than building against a managed API when your process, integrations or review steps are organisation-specific.

  • ASSESSMENT

    Vendor commitments are treated as unverified until we have fetched the page that makes them. Until then this option carries questions to ask, not assurances: a signed data processing agreement covering the data you will actually put in; a documented data residency commitment naming the region, in the contract rather than a blog post; a written no-training commitment for your content, including uploads and connected sources; stated retention periods and a deletion path you can exercise; an administrative audit log you can export, and SSO with group-based access control.

  • RECOMMENDATION

    No jurisdiction was named, so this is the check rather than the conclusion: compare the vendor's stated processing locations and subprocessor list against the cross-border transfer rules wherever you operate before uploading anything.


03Deployment stacks

0 published

No deployment stack has been written up for this use case yet.


04Tools by hosting option

1 tools

05Compliance hot spots

This use case usually raises high-risk ai, automated decision-making, bias and fairness, personal data, sensitive data, human oversight, transparency, retention, auditability.

High-risk AI
No published jurisdiction page names this topic yet
Automated decision-making
No published jurisdiction page names this topic yet
Bias and fairness
No published jurisdiction page names this topic yet
Personal data
No published jurisdiction page names this topic yet
Sensitive data
No published jurisdiction page names this topic yet
Human oversight
No published jurisdiction page names this topic yet
Transparency
No published jurisdiction page names this topic yet
Retention
No published jurisdiction page names this topic yet
Auditability
No published jurisdiction page names this topic yet

06Example questions

Each of these opens the question box with the text already in it. The answer is researched for your organisation, not for this page.

  1. 01Screen CVs for a high-volume hiring process.
  2. 02Match applicants to role requirements with a human decision step.
  3. 03Use AI in recruitment for a German team without breaking the rules.

Improve this page

Sign in to contribute

From the field

0 deployments · 0 questions

Nobody has reported deploying this here yet, and no question has been opened against this page. Both appear once a reviewer accepts them.