Issue 18: Is Your Workforce Training Your AI? Consent, Data Rights and Control

Digital Human Capital, Part 2 of 3

Originally published in The Compliance Edge at nimbleglobal.com, 22 September 2026 | This analysis is based on Nimble Global's proprietary research and 30+ years of practical experience across over 90 countries. | © 2019 - 2026 Nimble Global. All rights reserved.

The work product was never the whole asset.

In the first article in this series, I introduced the idea of digital human capital^®, the knowledge, judgement and experience of the workforce that organisations and the technology they use can capture alongside the work product itself. I keep coming back to that distinction because in my experience, it changes the conversation.

A note on scope before going further. Throughout this article, ‘workforce’ means everyone performing work for the organisation, i.e. full-time and part-time employees, agency workers, independent contractors, consultants, statement-of-work resources, and workers engaged through employer-of-record (EOR) or agent-of-record (AOR) arrangements. Governance should cover every engagement type, but the legal analysis and contractual response must reflect the relationship and jurisdiction. The recruitment examples also consider candidates who have not yet been engaged.

More Than the Finished Work

For decades, organisations have built contractual frameworks around a familiar workflow: a person performs work, the organisation pays for that work, and the contract and applicable law determine who owns the resulting intellectual property. Artificial intelligence does not necessarily disturb that arrangement, but it may be creating something alongside it many organisations have not yet considered. A workforce management example is a worker who reviews an AI-generated recommendation, corrects an output, rejects a candidate, changes a search or alters a piece of code. Depending on how the technology operates, the organisation or its provider may also accumulate a digital record of the judgement that produced the finished work.

Ownership of the report, the code, the design or the candidate shortlist does not settle what happens to the knowledge recorded while that work is being produced.

If a system records the corrections, choices, and interventions an experienced professional makes, and those interactions are later used to improve future outputs, the traditional line between work product and accumulated organisational knowledge blurs.

Recording an interaction is not the same as training an AI model. It may support a saved history, analytics or service improvement without changing the underlying model. Microsoft, for example, states that its commercial Copilot service stores interaction data but does not use prompts, responses or information accessed through Microsoft Graph to train foundation language models. The technology, configuration and terms need to be checked rather than assuming that every interaction trains AI.

We have spent decades perfecting the language of intellectual property ownership, confidentiality and the almighty protection of proprietary information. I am not convinced our contracts and governance frameworks evolved as quickly as the technology now used across our workplaces.

What the System Learns

Let’s keep it simple. A recruiter using an AI-enabled sourcing tool might identify a group of candidates and rank them according to whatever criteria sit behind the platform. The recruiter reviews the recommendations, rejects most of them, progresses a few and then changes the search based on experience that may have taken years to develop. Most of the people reading this will remember when that experience lived in Boolean search strings, i.e. the recruiter's own logic, often written by hand, refined through trial and error and carried from one platform to the next. The search string captured the logic of a particular search, but it did not necessarily capture why the recruiter changed it or how their judgement developed across assignments.

AI-enabled sourcing can reverse that relationship, and from what I have seen, the industry hasn't fully registered the change. In that model, the platform supplies the selection logic, and the recruiter responds to it rather than writing it. That shift has happened quickly and, in many organisations, without much reflection. Recruiters who once built every search themselves still set the requirements, but the matching, weighting and ranking that determine who appears, and in what order, can happen inside the platform, according to logic the recruiter did not write and often cannot see. The convenience is real. What is less visible is that each response, rejection, progression and refinement may become information the system retains. LinkedIn's Recommended Matches documentation, for example, identifies saved and contacted candidates as signals used in recommendations.

One decision may reveal very little. Thousands of those decisions may reveal patterns in that recruiter's selections. The finished shortlist may be the obvious asset, but it is possible that the far more valuable asset over time is the pattern of professional judgement captured along the way.

Broader Than Consent

In this example, the recruiter's recorded decisions and the candidate's information raise separate questions. The language of consent often enters the discussion, although I am not sure consent is always the most useful place to begin. The instinctive question is whether the recruiter or candidate agreed to information about them being used to train or improve an AI system, rather than simply for the recruitment process or day-to-day work.

That is certainly relevant, but the compliance questions are broader.

1.    What information is being collected?

2.    Why is it being collected?

3.    What is the lawful basis for doing so?

4.    What has the individual been told?

5.    Who else receives the information, how long is it retained, and is it later used for purposes that extend beyond the reason it was collected in the first place?

Readers familiar with data protection law will recognise these as core questions under the General Data Protection Regulation (GDPR) and the growing family of worldwide privacy legislation. That is precisely the point. These are not novel AI questions; they are established compliance questions that AI is now forcing organisations to answer in places they had not considered. In employment environments, consent can be a difficult basis to rely on because the employer-employee relationship is not necessarily one in which consent can always be considered freely given.

Simply adding another line to an employment agreement or another paragraph to a privacy notice does not necessarily resolve the underlying issue.

None of this yet touches AI-specific regulation, which is developing along strikingly different paths. The EU's AI Act has been in force since 2024, and parts of it already apply, but the principal high-risk requirements for systems classified under Annex III, including relevant recruitment and workforce management systems, were formally deferred in July 2026 and are due to apply from 2 December 2027. The UK, by contrast, has not enacted a comprehensive, cross-sector AI Act and continues to regulate through existing law and existing regulators. Nor is this a European conversation. South Korea's AI Basic Act came into force on 22 January 2026 and identifies recruitment as a high-impact area, with additional obligations where the statutory criteria are met. Its government has announced an enforcement grace period of at least one year, subject to exceptions for serious harm. Brazil's proposed AI framework remains before its Chamber of Deputies. What those diverging approaches mean for workforce management deserves an article of its own, and it will get one in the final part of this series.

Two Different Purposes

The distinction between doing work and improving a system matters. A worker may understand that entering information into a recruitment platform, a customer service tool, or an internal AI application is necessary to perform the job. That does not automatically mean the worker understands that the same interaction might also be retained, analysed or reused to improve the technology itself. Those are not necessarily the same purposes. One facilitates the work the person has been engaged to perform; the other may contribute to an organisational or commercial capability that survives long after the individual has finished that task.

Employment contracts and written statements of particulars can help explain these activities, but organisations should check whether the documents workers actually receive address them. A contractual clause may inform the worker; it does not by itself make the processing lawful. Whether those activities are lawful, appropriate or even problematic will depend very heavily on the circumstances and the jurisdictions involved, but organisations cannot make that assessment if they do not first know the second activity is happening.

Who Holds Which Rights

I also think we need to be careful with the language of data ownership. It is easy to say the organisation owns the work and assume everything surrounding its creation falls into the same bucket. It does not. Intellectual property is one set of rights. Personal data is governed by another. Confidential information, database rights and whatever the technology provider has secured contractually are different again, and they overlap in ways not immediately obvious. An organisation may own a consultant's final report and still have separate obligations concerning personal information generated through the consultant's interaction with a system. A technology provider may have contractual rights over certain categories of information entered into its platform, even though the client assumes the information remains entirely within its own control. That assumption may be anchored in the intellectual property and confidentiality provisions the client negotiated, and those provisions may be perfectly sound. They are also answering a different question. Ownership of deliverables and protection against disclosure do not, by themselves, settle whether interaction data can be retained, aggregated or reused for the provider's own purposes, and the language permitting that use may sit in documents the client has not negotiated.

The more useful question is therefore not simply, 'Who owns the data?', but who has the right to collect it, process it, retain it, transfer it and reuse it, and for what purpose.

Look at how these rights can be presented to individual users. For many platforms, the first encounter is a screen presenting terms and conditions, a box to tick and no way past it without ticking. The worker usually has no meaningful opportunity to negotiate those terms. Where the platform is required for an assignment, declining can mean being unable to obtain or perform the work.

Enterprise contracts can be negotiated, and procurement functions negotiate them, but workplace technology can also arrive outside that path, adopted directly by individuals and teams who click through terms that may not have been reviewed by anyone with negotiating authority. Clicking may amount to contractual acceptance, depending on the terms, the circumstances and applicable law. That is different from acknowledging a privacy notice or giving valid consent to personal-data processing. The question is whether anyone in the organisation knows what was accepted and by whom.

There is a partial protection here. A negotiated agreement can state expressly that its terms prevail over conflicting click-through or end-user terms for the services it covers. Procurement teams should confirm that the technologies workers actually touch are covered, and that the provider is contractually responsible for passing the relevant obligations to its subcontractors. Connected services may require separate review; a precedence clause does not automatically bind every third party. For technology adopted outside procurement, there may be no negotiated override of the end-user terms, although applicable law still governs. Closing that gap requires governance as well as drafting.

Follow the Data

Consider how this works in a typical contingent workforce programme. A Vendor Management System (VMS) may sit at the centre of the workflow, with workers, hiring managers, staffing suppliers, the managed service provider (MSP) and sometimes other service providers all interacting with it. Around that VMS sits an entire ecosystem of additional technologies: platforms that screen and verify, platforms that onboard and manage, and increasingly platforms that assess, i.e. technologies evaluating candidates for suitability, personality or fit. Information doesn't simply enter one system and stay there. It moves through a workflow involving multiple organisations and technologies, often crossing borders and sometimes being enriched, analysed or used to make decisions along the way.

One thing I have found interesting when reviewing workforce technology privacy and data protection frameworks is how neatly contractual language can describe relationships that are considerably less neat operationally. A provider may describe itself broadly as a processor, while elsewhere describing activities for which it appears to determine its own purposes or the essential means of processing. Choosing non-essential technical details does not, by itself, make a processor a controller. An MSP encounters the same problem. The difficulty is that controller and processor are not necessarily permanent labels that can simply be attached to an organisation for everything it does. The role depends on the processing activity. Follow the data through an actual workforce workflow and the same party may act as a processor at one point and a controller for another activity, while another participant may be a separate controller, joint controller or subprocessor depending on what is actually happening to the information.

The Information Commissioner's Office (ICO) found this problem in its 2024 AI in Recruitment Outcomes Report: some providers had incorrectly described themselves as processors rather than controllers. It also told recruiters to establish whether candidate information was being used to train, test or develop AI products. The report distinguishes a bespoke tool trained solely on a recruiter's instructions from a central tool trained for use across several recruiters, for which the provider is the controller for that processing.

The distinction matters because workforce data rarely follows the clean organisational chart shown in the contract. A candidate's information might originate with a staffing supplier, enter the VMS, become available to the MSP and client, move to a background screening provider, pass through an identity verification service and ultimately become part of the worker's ongoing engagement record. Each participant may have a legitimate reason for receiving some of that information, but each processing activity needs to be understood on its own terms. Understanding that workflow requires more than a list of recipients.

Responsibility also depends on who decided what would happen to the information at each step.

1.    Who decided what information is required?

2.    Who decided to restrict employment opportunities based on acceptance of a click-wrap agreement?

3.    Who determined why the information was collected?

4.    Who determined what would happen to it?

5.    On whose instructions was it processed?

6.    Was it subsequently used for another purpose?

7.    Was it retained for the provider's own regulatory, analytical, security or product-development purposes?

8.    Was it ever deleted, and how?

The answers may change as the same piece of information moves through the workflow. This is why I have become increasingly uncomfortable with privacy documentation that simply announces that a platform is ‘GDPR compliant’ or describes the provider as ‘the processor’ without explaining the underlying processing activities.

Over several years I have reviewed a number of privacy and data protection frameworks within the workforce technology ecosystem, and the recurring issue has not been the absence of privacy language. There is usually plenty of it. The problem is whether the language accurately describes what happens operationally once real worker data begins moving through the system.

This is the click-box problem again, at its sharpest. Declining is technically possible, but if using the VMS, an applicant tracking system (ATS) or similar technology, completing the background check or submitting information through the onboarding platform is necessary to obtain or perform the assignment, the practical choice may be considerably narrower than the screen suggests. Suppliers and hiring managers can find themselves in much the same position: acceptance is simply the price of entering the system.

That becomes particularly important as these technologies introduce artificial intelligence. Data originally collected to administer an assignment, verify identity, assess skills, conduct a background check or manage a contingent workforce programme may now have another potential value. It can contribute to analytics, benchmarking, automated decision-making, product development or, depending upon the technology, applicable law and contractual terms, the improvement of AI-enabled systems.

A record that somebody clicked ‘I agree’ does not answer those questions.

Organisations responsible for workforce management need to understand the complete data lifecycle, including every party that touches the information, the role each party performs for each processing activity, and every knock-on use the information may be put to.

When the Worker Leaves

I am particularly interested in what happens when the worker leaves. Traditional workforce processes have a recognisable end point. Access is removed, equipment returned, final payments processed and records are retained or deleted according to the organisation's legal and business requirements. Digital human capital does not disappear so neatly. If an individual spends three years correcting recommendations, refining outputs and repeatedly applying specialist judgement inside an AI-enabled system, the effect of those interactions may remain after the individual has gone. Their account can be deleted and their laptop wiped, but the system may still be better because they were there.

Deleting an account or source records does not establish whether a trained model still contains personal data. The European Data Protection Board's Opinion 28/2024 calls for a case-by-case assessment of whether a model trained on personal data can be considered anonymous. Offboarding therefore needs to distinguish access removal, record deletion and any continuing model-related processing.

That creates an unusual form of organisational value. A highly experienced professional may spend years building knowledge before joining an organisation, apply that knowledge during an engagement and then leave, while some of the value of that experience remains embedded in technology they helped improve. There is nothing inherently improper about that. Organisations have always accumulated institutional knowledge from the people who work within them. What is different is the scale, durability and potential replicability of what can now be captured.

Informal knowledge could be lost when the person carrying it left, although organisations also retained it through colleagues, records and processes. Technology may now allow more of that knowledge to remain available and reusable.

Contractors make that question particularly interesting because organisations often engage independent specialists precisely for expertise developed elsewhere, i.e. across competitors and adjacent industries. I have watched automotive and defence run on this model for decades. A consultant may bring twenty years of experience, a recruiter may have developed a highly effective sourcing methodology and an engineer may possess specialist judgement built across multiple clients and industries. Traditionally, the organisation purchases access to that expertise for a defined period or purpose. If AI-enabled systems begin capturing enough of the decisions, corrections and methods used by that contractor to reproduce elements of the expertise later, the economics of the relationship start to change.

An organisation may be acquiring something more enduring than the temporary access it believed it was purchasing.

Again, that does not mean the organisation has done anything wrong. It means the contracts need to be examined more carefully. A clause assigning ownership of project deliverables may not address the contractor's pre-existing methodologies, and a confidentiality provision may protect the client's information without saying how the contractor's own know-how is treated. The technology clause may authorise use of a platform yet be silent on whether interactions can be retained for product or model development. The privacy notice may describe monitoring but say nothing about AI training. I suspect the problem will not be that organisations consciously chose an inappropriate structure. It will simply be that the contractual architecture was written for a form of work that technology has already moved beyond.

The Space Between Decisions

Organisations need to know whether customer or worker information can be used for model training, fine-tuning, analytics or service improvement. They need to know what happens to interaction data after the engagement ends, and whether information moves internationally or through third-party AI providers. Above all, they need to know whether any of that activity can be switched off, deleted or restricted when required.

The governance challenge is that responsibility for those questions sits across multiple functions. Contract and supplier decisions need input from legal, privacy and procurement teams, while information security and technology teams need to establish what the platform actually does and how it is configured. HR and contingent workforce teams bring the worker relationship into that assessment. These functions need a shared account of the information being collected and reused, rather than separate approvals that never meet.

That requires someone to look across the entire chain.

I would expect a documented map of each processing activity: the information involved, its purpose, the responsible parties, the lawful basis, permitted reuse, retention and applicable controls. Where processing is likely to result in a high risk to individuals' rights and freedoms, GDPR requires a data protection impact assessment before it begins.

The longer I work in workforce compliance, the more often I find the real risk is not created by something an organisation deliberately decided to do. It is created in the space between different decisions that each made sense on their own. The platform was approved. The supplier was contracted. The privacy notice was issued. The worker was onboarded. Somewhere along the way, the organisation started collecting something nobody had originally defined.

That information may become valuable. It may preserve institutional knowledge, improve productivity, reduce dependency on particular individuals and allow organisations to retain capabilities that might otherwise diminish when people leave. But value does not remove obligation. If organisations intend to capture and use digital human capital, they need to understand what they are collecting, why they are collecting it, what rights they have to retain and reuse it and what rights their technology providers may have acquired along the way.

An old episode of Star Trek: The Next Generation, 'The Measure of a Man', staged a hearing over whether an android officer was a person or property, and whether everything he was could simply be studied and replicated. Science fiction asked that question about a machine. We are quietly answering it about people, one interaction at a time.

Stay Nimble. Stay Compliant.

About the Author: With extensive experience in workforce compliance and global workforce solutions, David Ballew has consistently driven innovation and operational excellence. As the Founder and CEO of Nimble Global, David combines deep industry expertise with a unique perspective shaped by his neurodiverse AuDHD profile, enabling creative problem-solving and multidimensional insight. A pioneer in MSP models and workforce technologies, he is dedicated to bridging global compliance gaps and helping organisations build resilient, future-ready workforces.

Real People. Real Action. Real Innovation.

Disclaimer: This content is intended for informational purposes only and does not constitute legal, tax, or employment advice. Readers should consult qualified professionals in relevant jurisdictions before acting on the guidance provided. Nimble Global disclaims any liability for actions taken based on this publication.

Digital Human Capital^® is a registered UK trade mark of Nimble Global Ltd.