Originally published in The Compliance Edge at nimbleglobal.com, 27 August 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.

Nothing New Under the Sun

A senior external workforce leader responsible for a global programme recently said something I suspect some of you have thought, but few have said out loud. Three months after go-live on a Managed Service Provider (MSP) programme, reviewing it against the promises made during the sales and implementation process, the verdict was blunt and from a place of frustration: ‘pick an MSP, any MSP, they all do similar things, they all run a VMS, and when you line them up, including pricing, I struggle to find a meaningful difference between them.’ Thirty years in this industry, and I didn’t argue.

The implementation projects are no different. I have reviewed dozens over the years, and they contain the same elements in roughly the same order, all competent, necessary, and completely interchangeable. That executive went on to say, ‘I attend the industry events, the ones most of us complain about but turn up to anyway for the parties and the reunions, and it feels like there’s nothing new under the sun, and it's a stretch to find [meaningful] innovation’.

The thinking goes like this… pick your service and technology provider, because at the platform level, the ‘providers’ are much the same; their names are interchangeable. Harsh, perhaps, but this attitude is prevalent yet mostly unspoken for fear of retribution, either from their employer, colleagues or the industry.

So if the technology is commoditised and the playbooks are nearly identical, where does the difference actually live? Because there is a difference. Anyone who has run these programmes knows that some providers deliver, some try with best efforts, and some fail, and the gap between them can be massive.

The difference lives in delivery. It lives in the experienced project manager who spots the problem three weeks before it becomes a crisis. The account lead who has seen this exact failure mode many times before and re-routes around it without fanfare. The compliance analyst who looks at a worker classification that the system waved through and thinks, no, that is not right and can explain why from a business and legal perspective. The differentiator is not the platform. It is the judgement of the people solutioning, configuring, testing, and maintaining it.

The Nimble Global ethos has been the same since day one: ‘real people’, taking ‘real action’, and delivering ‘real innovation’. We did not write those words with AI in mind, but they have never mattered more. Strip away the interchangeable platforms and the near-identical playbooks, and what remains is people, acting on judgement, innovating in the moments no workflow anticipated.

That is the asset this article is about. That judgement, the accumulated pattern recognition that separates a good programme from an interchangeable one, is now being systematically extracted. And almost nobody has asked a simple question: who owns it?

Naming the Asset

Our industry lacks precise language for what is created when human expertise flows into digital systems. And in compliance, imprecise language is where problems hide, sometimes for a long time until they can no longer remain silent.

Consider what actually happens inside a modern workforce programme. Every escalation resolved teaches AI something. Every classification decision corrected, every workflow exception handled, every edge case flagged by an experienced professional becomes an input the AI tool learns from.

• Is this ‘training data’? The term is too narrow. It misses the behavioural residue, the patterns of decision-making that transcend individual data points.

• Is it ‘intellectual property’? Too broad, and it conflates two very different things: the knowledge a worker carries and the assets a company owns.

• Is it ‘worker data’? That collapses the question into personal data protection frameworks that were designed for an entirely different problem.

Nimble Global adopted a term for it: Digital Human Capital®. The measurable value created when human expertise, knowledge, and labour are converted into training data, algorithmic inputs, or machine-readable intellectual assets through interaction with digital tools and platforms. That's a mouthful, but worth digesting. We considered the definition important enough to register the term as a UK trade mark, because you cannot govern an asset you cannot name.

But naming it is the easy part. The harder question is the one that opened this section.

Who owns what is rolling around in my brain?

If this sounds like an episode from the television series ‘Twilight Zone’ (1959), keep reading. Let me make this personal, because the abstraction hides the stakes.

As a consultant, I am paid to provide a service. That service is built on over three decades of accumulated experience, judgement formed across thousands of engagements, mistakes made and learned from, patterns recognised because I have seen them fail before. When I deliver that service, the work product is clear, but the expertise behind it, the thing that is quite literally rolling around in my brain… who owns that? And when that expertise passes through a client's platform, and the platform learns from it, who owns what the platform learned?

English law answers some of this, and it is worth being precise about what it settles and where I believe it stops. None of what follows is legal advice; it is a practitioner's map of the terrain.

For employees, the position on work product is well established. Under section 11(2) of the Copyright, Designs and Patents Act 1988, copyright in a work created by an employee in the course of employment belongs to the employer. For the expanded and rapidly growing workforce of independent contractors, the default position reverses: the contractor owns the copyright in what they create unless the contract assigns it. In my experience, a surprising proportion of supply chains, staffing, and statement of work (SOW) contracts get this basic allocation wrong, or worse, simply never address it.

Let’s get technical for a minute… on the knowledge itself, the leading authority remains Faccenda Chicken v Fowler, decided by the Court of Appeal in 1986. The court drew a distinction that remains the starting point today: an employer's trade secrets can be protected even after the employment ends, but a worker's general skill, knowledge, and experience belong to the worker and travel with them.

So far, so settled. My accumulated expertise is mine. Specific confidential material I was exposed to is not. My deliverables belong to whoever the contract says they belong to.

For readers outside the UK, which is many of you: I use English law as the lens because it is the one I work under, but the pattern repeats across legal systems worldwide, even where the mechanics differ. In the United States, the work made for hire doctrine gives employers ownership of works their employees create, while independent contractors generally keep what they create unless a written agreement says otherwise. Many civil law jurisdictions start from the opposite premise, vesting rights first in the individual creator, with the employer taking a transfer by operation of law or by contract, and some surprisingly recognise moral rights that cannot be assigned at all. The details matter enormously, and nothing in this article is legal advice for any jurisdiction, including my own. But notice the consistent pattern: virtually every legal system has an answer for who owns the work product, and nearly every one draws a boundary somewhere between the knowledge a worker carries away and the secrets an employer keeps.

But here is where the law runs out and this article becomes critical to current workforce practices regardless of where you sit. Neither the 1988 Act nor Faccenda anticipated a third category of output, and to my knowledge no other jurisdiction has resolved it either. I am not alone in that assessment. In March 2026, the UK government published its statutory report on copyright and artificial intelligence, conceding that copyright law drafted long before generative AI does not provide clear answers, and declining to legislate for now. That report concerned the training of AI on copyrighted works, a neighbouring question to the one in front of us, but the concession travels: the frameworks predate the problem, and the gap we are discussing here was not even on the table.

When my expertise flows through an AI-enabled platform, the value extracted is not a ‘work’ in the copyright sense. It is not a trade secret in the Faccenda sense. It is something else: corrections, validations, the shape of how an experienced practitioner decides.

No standard assignment clause captures it, because nobody drafted for it

The frameworks we rely on were built for documents and secrets, not for behavioural residue. Wherever you are reading this, the test is the same: ask what your own jurisdiction's frameworks were built to protect, and whether this new category fits cleanly inside any of them. I have yet to find one where it does.

Three Claimants and a Silent Contract

Now place this inside an external workforce supply chain, and the problem compounds. Picture a fictional but entirely plausible arrangement. A staffing supplier places experienced compliance analysts into an end client's programme. The client runs an AI-enabled worker classification tool, licensed from a technology vendor. Over eighteen months, those analysts correct the tool's errors, validate its borderline decisions, and flag the edge cases it misses. The tool gets measurably better. The client's vendor then incorporates those improvements into the product it sells to every other customer in the market. Who owns the improvement?

There are at least three claimants.

1.    The workers, whose judgement did the teaching.

2.    The supplier, whose employees or contractors they are.

3.    The end client, whose systems and whose commercial relationship with the technology vendor made the learning possible.

And the second claimant is not one thing. A contingent staffing supplier provides a person, and that person may be the supplier's employee or an independent contractor, which, as we saw earlier, changes who owns what by default. A statement of work (SOW) supplier provides an outcome, project-based deliverables, and the people producing them are typically, though not always, the supplier's own employees. The SOW contract usually assigns the deliverables to the client and stops there. But the judgement those people exercise inside the client's platforms, the supplier's accumulated methodology expressed through its workforce, is exactly the residue nobody drafted for. The engagement model changes the strength of each claim, and in most programmes, nobody at the table has noticed that it matters.

In most master services agreements I review, the answer is nowhere. The IP clauses address deliverables. The confidentiality clauses address information disclosed. Neither says a word about what the platforms learned along this complex journey.

If you're reaching for the data protection agreement, I understand the instinct, but it answers a different question. Data protection law governs whether personal data about identifiable people may be processed, on what lawful basis, and for what purposes, and a platform learning from worker activity can certainly engage it. What it does not do, anywhere, is allocate ownership of the value created. Privacy law protects the person; it says nothing about the asset. The same goes for the data security schedule, which defends the data from the outside world while saying nothing about what the platform's own vendor extracts from within. You can be fully compliant with every data protection and security obligation in the contract and still be giving the asset away.

That silence is commercial exposure, plain and simple, sitting unexamined in supply chains across every industry that uses contingent labour, which is all of them.

• The supplier in my scenario has, without noticing, funded the improvement of a product that will be used to reduce its own margin.

• The workers have trained their least tired, least expensive replacement.

• The end client may discover that value it assumed it owned has walked out the door inside somebody else's product.

The Setting That Defeats the Contract

Let’s go deeper. This problem has a second layer, and it is the one most likely to hurt you first because it doesn't require anyone to breach anything.

Not all AI tools secure what you put into them. Whether your inputs stay yours or flow into the vendor's underlying models, what I think of as the big AI brain, very often comes down to neither law nor negotiation, but to subscription tier and security settings. Enterprise agreements from the major AI vendors typically include commitments that customer inputs will not be used to train their models. Consumer and free tiers, in many cases, carry no such commitment, and some treat your inputs as fair game for model improvement unless a setting says otherwise. The difference between protected and harvested can be a checkbox, and it assumes the checkbox is easy to find and understand. Often it is neither. The settings that govern this are frequently written in reverse logic, where yes means no and no means yes. The option that sounds generous, ‘help improve the model’, ‘share your data to make the product better for everyone’, is the one that gives your inputs away. Agree to the friendly toggle, and you have declined protection. Refuse it, and you have secured what you assumed you already had. A worker moving quickly through a setup screen, trained by years of waving through cookie banners and terms of service, will accept the agreeable option every time. Whether that wording is careless or deliberate is up to you, but notice the friction always runs in one direction, towards sharing.

Now consider how this plays out in practice. Your organisation negotiates a careful enterprise agreement with an AI vendor. The contract says the right things. But an analyst on your programme, or on your supplier's programme, finds the sanctioned tool clunky and pastes the same material into a free account on their personal login…

• or the enterprise tenancy was provisioned with a default setting nobody reviewed,

• or a team adopts a promising new tool on a standard subscription while procurement is still evaluating it, and by the time the paperwork catches up, six months of judgement, corrections, and client context have already gone into somebody else's training pipeline.

Even with the best intentions, this happens every day worldwide.

Nothing in that sequence is dramatic. No rogue actor, no hack, no breach of contract in the ordinary sense, but there is a breach of intent: the gap between the protection you believed you had in place and the protection your actual configuration delivered. Unlike a contractual breach, there is no counterparty to pursue and no remedy to invoke. You read that right. The expertise is simply gone, absorbed into a model you do not control, serving customers you will never meet, including, with high probability, your competitors.

This is why the ownership question and the configuration question have to be asked together. A contract that secures Digital Human Capital on paper, sitting on top of tooling that leaks it in practice, is not protection. It documents what you meant to do.

The Questions to Ask Today

This issue has two practical steps, because the exposure runs through both your contracts and your configurations.

1.    Revisit the IP assignment and confidentiality clauses in your key workforce agreements, on both the buy side and the supply side, and ask: does this clause capture anything beyond deliverables and disclosed information? Does it say anything about what systems learn from the people working within them?

2.    Ask whoever owns your AI tooling to show you, not tell you, the actual settings. Which tools are in use across the programme, including the ones nobody formally approved. Which subscription tier each one sits on. Whether the commitment not to train on your inputs exists in the agreement, in the configuration, in both, or in neither. And often more important, whether your suppliers can answer the same questions about their own people, because their leak is your leak.

In almost every contract I have reviewed, the honest answer to the first question is no. In almost every organisation I have asked, nobody can fully answer the second. That doesn't mean you are in breach of anything. It means you are holding an asset, or giving one away, that your contracts do not know exists. And in compliance, the risks that hurt most are rarely the ones you assessed and accepted. They are the ones nobody thought to name. In simple terms, you didn’t know what you didn’t know.

What Comes Next

A tougher problem lies underneath this one. The Digital Human Capital being harvested by these systems has a source: experienced practitioners, people who built their judgement over decades. That population is leaving the workforce in numbers, and the mechanism that once created their successors, learning at the elbow of someone who had seen it all before, has quietly disappeared from working life, traded away for a luxury many now label working ‘remote’. The conversations overheard at the coffee station, in the hallway, and most often over the wall of the cube next to yours. Meanwhile, the people replacing them are handed AI outputs they often lack the experience to evaluate. They do not know what they do not know, and so error passes as fact.

This means the asset we have just struggled to name is being drained at both ends: extracted at the top, and no longer formed at the bottom. Where that leaves us, for both the external workforce and the permanent one, is where we go in the next Compliance Edge issue.

Compliance has always been about seeing the risk before it has a name. This one now has a name. The question is what we do with it.

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.