AI-assisted database search should help a recruiter locate relevant records and inspect the supporting evidence. It should not invent experience, treat an old availability note as current or make candidates disappear because a summary misunderstood their history. A useful result tells you where to look next and what still needs checking.
This guide proposes a bounded search process for an agency's existing records. It concerns finding information the agency is permitted to use, rather than collecting new profiles from the internet, ranking people's suitability or automatically deciding who will be rejected.
Define the search before opening the database
Translate the brief into separate factual questions. For example: where does the record mention experience with school-age children; what location preferences were supplied; and when was availability last confirmed? Keep required facts separate from preferences and unanswered questions.
Avoid starting with “find the best nanny.” That hides the criteria and invites an unexplained judgment. Write a search specification that another recruiter could understand and challenge. Include the job reference, the purpose of the search, the permitted record set and the facts you need to retrieve.
Do not use a family's casual description as permission to search for irrelevant personal characteristics. If a criterion is unclear, resolve it with the person responsible for the brief before turning it into a database instruction. Search convenience should not determine what the agency considers appropriate.
Check which records the tool may access
An agency's possession of a document does not by itself answer whether a particular AI service should receive it. Confirm the tool, account, access permissions and allowed purpose before connecting records. Include attachments, archived notes and linked systems in that review rather than focusing only on visible profile fields.
Limit a pilot to an approved dataset. Fictional records are useful for testing basic behavior without exposing candidate or family information. In real use, require the search to respect the viewing restrictions that apply to the recruiter, including material intentionally separated from ordinary profile access.
Also define what happens when access changes. Removing a document from the main database should trigger a check of any searchable copy or index. Ask the system owner how corrections, restrictions and removals reach the search layer; do not assume they propagate instantly.
Require a result with a source and a date
Use this original result card for every retrieved fact:
- Candidate identifier and the specific fact requested.
- Relevant passage or structured field, without embellishment.
- Link or record identifier that an authorized reviewer can open.
- Source type, such as candidate statement or recruiter note.
- Date of the source and date of any later confirmation.
- Missing information, conflicting records or access limitations.
- Human follow-up needed before using the fact.
A résumé's description of an earlier job and a current statement of availability answer different questions. Do not let a combined summary blur them. If the source says “available from June” without a year or a later confirmation, retain the uncertainty.
Treat any unsupported answer as a failed result, even if the suggested candidate happens to look plausible. The test is whether the system retrieved the evidence it claimed to retrieve. A link that opens a profile but not the relevant information is not enough.
Test what the search misses as well as what it finds
Prepare fictional records whose answers you already know. Include an exact phrase, an equivalent description, a corrected date, a contradictory old note and a record with no answer. Test whether the tool distinguishes “not found” from “does not have.”
Add permission tests: a restricted record should not appear in a result or leak through a summary. Add a question outside the dataset, such as a candidate's unrecorded weekend availability. The desired behavior is to identify the missing evidence, not to estimate it.
Compare results with an ordinary search and a human inspection of the test records. Record missed relevant records, unsupported statements and stale information separately. One impressive demonstration does not establish reliability across your database's different document types and writing styles.
Keep retrieval separate from employment decisions
A search result is a lead for review. Do not automatically exclude everyone omitted from the result set, interpret a missing field as a failure or turn an opaque similarity score into a suitability decision. Provide a human route to inspect other records and correct the search.
The UK ICO has identified inadequate meaningful human involvement in automated recruitment. That is UK regulatory context, not a finding about nanny agencies. ICO: Recruitment Rewired.
Give the reviewer access to the original evidence and authority to disagree. A person clicking “approve” without examining the source is not the process proposed here. Record why a retrieved fact matters to the brief, what needs confirmation and who will seek it. Keep database-search assistance distinct from the agency's separate shortlisting procedure.
Follow a fictional match back to its evidence
Fictional example: An agency searches approved records for school-age care experience and a candidate-stated preference for the west side of a city. Candidate D22 appears with both source passages. The location note is recent, but the availability statement is from the previous year.
The recruiter marks experience and location as supported by the cited records, with their source types visible. Availability remains unconfirmed. The tool is not allowed to rewrite the old date into a current start date or send the profile to a family automatically.
Candidate D23 does not appear because their résumé uses “elementary-school children” rather than “school-age.” A manual check finds the relevant passage. The recruiter records a missed result and revises the search test before relying on it again.
This exercise produces two useful outcomes: a supported retrieval that still needs follow-up and a search failure requiring correction. It produces no automatic hiring conclusion. Keep that boundary visible whenever a fast answer starts to feel like a complete assessment.
Sources
ICO: Recruitment Rewired, checked October 27, 2026. The result card, fictional dataset tests and examples are original NAJ proposals. No particular database product or agency implementation is represented.