THE PRACTICAL VIEW
Read access and permission to take action should be designed separately. The fact that a model can propose an update does not mean it should be allowed to write it to a system.
Start with a useful, bounded task
A recruiter might ask for a draft client update based on approved notes, or a summary of outstanding onboarding information. Define exactly which records are relevant and which output is expected. Keep the initial scope small enough to test thoroughly.
Check the service’s data arrangements
Review retention, access, model training terms, hosting, subprocessors and deletion arrangements for the actual product and configuration. A paid plan or an ‘enterprise’ label does not by itself establish that a use case is appropriate. Use approved tools and information under your organisation’s policies.
WORKED EXAMPLE · ILLUSTRATIVE
Draft the update, then test the handover
Take a weekly vacancy update. The workflow retrieves approved job and candidate-stage information, prepares a draft and places it in a review queue. The consultant checks the facts and recipients. After approval, an authorised action sends the message and records the activity. Each step should have an observable outcome and a way to recover if it fails.
Where it can go wrong
Test what happens when two clients share a similar name, the contact has left, or a candidate stage changed after the draft was prepared. A convincing message sent to the wrong person is a workflow failure even if the language is excellent.
Separate retrieval from action
Retrieving records for an answer requires permission to read. Updating a profile or sending a message requires a separate authority to act. Apply minimum necessary access and validate the target record. A model’s suggestion should not bypass the controls of the connected system.
Provide relevant business context
Agree terminology, field meanings, matching rules and the source of truth. Retrieval augmented generation can supply relevant material, but the output still needs checking. Ask the system to identify gaps and supporting sources instead of making unsupported assertions.
Design the handover
Define which outcomes require a recruiter’s review, what an exception looks like and who receives it. Record the proposed action, supporting information and final decision. Provide a practical way to pause the workflow and recover from an incorrect update.
Test the whole chain
Check permissions, matching, output quality and downstream records, not just the model response. Train people on what the workflow can and cannot do. Ella’s configuration is built around the business’s agreed data sources, roles and permitted actions rather than unrestricted access to every system.
PUT IT TO WORK
Take this into your next team conversation
Tick off the points you have covered. This is a working checklist, not a compliance score. Selections reset when you leave the page.
0 of 4 points covered
Questions worth asking
Does buying an enterprise plan settle the privacy question?
No. Assess the actual service, settings, contract and use case. Review what information is processed, where it goes, who can access it and how long it is retained. A plan name does not replace that assessment.
Can an LLM connect every tool in our recruitment tech stack?
Connectivity depends on each system’s capabilities, permissions, available interfaces and commercial arrangements. Validate the required integration during discovery rather than assuming universal access.
Further reading
For data-use decisions, refer to the OAIC’s guidance on commercially available AI products. For a structured risk-management reference, see the NIST AI Risk Management Framework. These sources support further assessment; they do not validate an individual product or configuration.
Continue with RAG Explained for Recruitment Agencies.
This guide builds on Jordan’s Hyper Automate resource library, updated for Wiity. Worked examples illustrate the approach; they are not customer case studies.