In an earlier piece, I described a working group looking at the same process map - an engineer, a controller, a manager - each of them leaving the meeting having learned something different from it. The document belonged to the company. What each of them took away from it never really belonged to anyone, not because anyone decided that, but because there was no way to get at it and claim it even if someone had wanted to. It’s the comfortable fiction employment has always relied on: you keep your experience, we keep the work product. Read more here.
That fiction survived for the entire history of employment because the knowledge lived only in people’s heads - it faded, mixed with everything else a person learned before and after, and there was no practical way for a company to claim it even if it wanted to. It isn’t yet true that a system can capture that knowledge with the same fidelity a career’s worth of lived experience has. Today’s systems mostly capture exhaust - corrections, phrasing, the sequence of calls someone made - not the understanding behind them. But the gap between what gets captured and what actually lived in someone’s head is closing, not holding steady, and closing it faster is the explicit direction every serious AI-at-work product is being built toward. Waiting until that gap is fully closed before arguing about who owns what it captures means negotiating from a position with no leverage left. That’s the urgency here - not a claim that today’s systems already have it, but that the trajectory doesn’t leave much time to argue about it once they do.
When your employer builds an internal AI system that learns from every document you produce, every correction you make, every decision you talk through with a colleague, more of that knowledge stops being fuzzy and starts being a queryable, persistent asset - one the company can now plausibly claim it owns, the same way it’s always owned the deliverable. And here’s the part I want to be careful about: I’m not arguing that claim is completely wrong - or completely right. I’m arguing it’s being asserted by default, unilaterally, by the side that happens to control the infrastructure - without the negotiation that a genuinely new form of property should get. It stops being fine to leave the question open the moment one side gets the unilateral ability to close it.
The obvious objection: your employer already owns your laptop, your CRM, your inbox - why is the AI layer categorically different? Because those are containers for company data. What’s different about a system that learns from how you work is that it doesn’t just store what the company already owned - it extracts and retains the part that was never the company’s to begin with: the judgment, the pattern recognition, the thing that made you worth hiring over someone else with the same job title. A laptop doesn’t learn your reasoning. This is starting to.
What’s changed recently isn’t the underlying problem - it’s who’s complaining about it. Enterprise AI leadership is increasingly arguing that companies need a hard boundary against their own AI vendors: that the corrections, usage patterns, and institutional judgment a company generates while using a model shouldn’t just flow upward into the vendor’s learning loop for free. Satya Nadella made exactly this case recently, arguing that enterprises need to own their “learning infrastructure” the same way they’ve historically owned their data. The reverse information paradox
But here’s what worries me about this argument becoming enterprise AI orthodoxy: I don’t expect it to travel downward. I expect companies to adopt exactly this reasoning for themselves - “we need to own our learning loop, nothing crosses the boundary without consent” - while continuing to apply the opposite logic to their own employees. The infrastructure that would enforce this is already sitting in most companies: it’s called data loss prevention (DLP), it was built for an entirely different reason, but it’s perfectly positioned to prevent employees from doing to their employer’s data what their employer now wants to do to its AI vendor’s reach. If anything, an enterprise that’s just convinced itself that learning-capture asymmetry is a real injustice worth building infrastructure against is an enterprise more likely to lock things down further, not less - now with a strategic rationale instead of just a compliance reflex.
This isn’t a hypothetical drift I’m worried about. It’s not just Nadella, either - it’s the live pattern across the software world right now, as AI platform vendors start absorbing or threatening the very categories of product built on top of them, and the companies caught in that relationship are having to choose, in real time, whether to fight it or lean into it. The vocabulary for “we deserve a boundary against whoever sits above us in this relationship” is spreading fast. It just isn’t spreading downward, to the people who sit below the enterprise in the same relationship.
So here’s what I think needs to happen. The floor below - obligation, portability, tiered certification - is meant to be a real mechanism, specified with the rigor it needs to survive contact with an actual policy conversation, not a placeholder gesture. What stays deliberately open is the harder question underneath it: what actually counts as company IP versus an employee’s own developed capability. That’s not a gap in the proposal. It’s the point of it - a floor that keeps that negotiation possible, rather than something that lets one side close it before the negotiation even starts.
Employees should have an obligation, not just a right, to bring their own AI to work - and companies should be required to accommodate it. I’m choosing “obligation” deliberately over “right,” because a right is something you can be talked out of exercising, and I don’t think this should be optional in either direction. It’s closer to how showing up with your own judgment and experience is already an implicit part of what you’re expected to bring to a job - this just makes explicit that your cognitive tooling comes with you too.
Corporate data and cybersecurity policy isn’t mine to write - it hasn’t been for a while - but I’ve sat close enough to how it gets made for long enough to know it will not arrive here on its own. The default is control, and it’s a reasonable default given what companies are actually trying to protect. Nobody inside that process is going to independently propose “let employees build their own cognitive tooling on the side.” Getting past that requires something imposed from outside the decision, not requested from within it - the same way an enterprise can walk away from a bad AI vendor in a way an employee structurally cannot walk away from a job. That asymmetry in exit power is exactly why this can’t be left to a negotiation between the two sides the way vendor contracts can be. Enterprises get to demand a trust boundary and mean it, because they can leave if they don’t get one. Employees need the boundary imposed on their behalf precisely because most of them can’t.
The obvious next question: who pays? I don’t think this creates a genuinely new inequity, though it’s a fair thing to ask. Employees already absorb some cost of the tools of their trade in plenty of professions - their own devices, certifications, sometimes their own vehicle or work attire - often with the expectation, and in many places the tax treatment, that this is a normal cost of doing the job rather than a hardship the employer owes them relief from. A capable personal AI subscription today costs about what a mobile phone plan does, and if this proposal actually works, competition among certified providers should push that down further, not up. Where I’d keep watching this closely is whether the quality gap between what a well-resourced employee can build and what a modestly-resourced one can only afford turns into its own stratification - augmented employees versus unaugmented ones, running alongside the corporate-versus-individual asymmetry this piece is actually about. That’s a real risk. I don’t think it’s an argument against the obligation, but it is a reason to watch closely how it gets implemented.
It’s tempting to hear “bring your own AI” and picture an employee with a personal chatbot open in a side tab, occasionally useful, easily ignored. That’s not the shift I actually mean, and it’s not the urgent part. The urgent part is agents - AI systems integrated with the company’s systems, that don’t just discuss your work with you but act on it: summarizing your e-mail, drafting the deliverable, executing the workflow, making the intermediate calls that used to require your judgment. Companies are already moving fast to deploy exactly this kind of tooling, company-owned and company-directed, wrapped around employees rather than handed to them.
That’s a different and worse version of the asymmetry I described above. A chatbot you consult still requires you to think, and thinking is what generates the pattern recognition that’s supposedly yours to keep. An agent that acts on your behalf can quietly remove you from that loop altogether - the judgment gets exercised by the system, on the company’s infrastructure, and there’s no moment where it was ever “in your head” to begin with. If the only fight is over who gets to keep the record of a conversation, we’ve missed the bigger shift already underway: from AI that companies use to augment their employees, to AI that employees need to be able to use to augment themselves - agents included, not just assistants. Everything below applies to both, but I wanted the agent case named explicitly, because it’s the one most likely to arrive first and get least noticed. So read “bring your own AI” as covering both assistants and agents, and your own delegated action along with your own thinking.
This needs a floor and it needs to leave the rest to the market, and I think those are two different kinds of decisions that shouldn’t be resolved the same way.
The floor: portability. Whatever platform an employee uses for their personal AI, they need to be able to export their own interaction data - not in some proprietary lock-in format, but in an open, genuinely reusable structure - and import it somewhere else. This already exists in a basic form; most providers today let you export your data. What doesn’t exist yet is a guarantee that the export is actually usable rather than technically-compliant confetti - a raw text dump with no structure, no threading, no way to reconstruct anything from it. That’s not a hypothetical failure mode: GDPR’s Article 20 already created a general right to data portability, and its well-documented result is close to exactly this - exports that are legally sufficient and practically close to useless. That’s why this can’t simply inherit GDPR’s language. A general portability right gets satisfied at whatever bar survives an audit; it needs its own, more specific requirement on what a usable export actually has to contain. That’s the one place I’d want any actual legislative language to be more specific than “open format,” even while keeping the argument itself accessible: the substance of what’s preserved matters more than the file extension.
What the floor doesn’t guarantee, on purpose: exporting your raw interaction history doesn’t hand you an identical relationship somewhere else. Understanding isn’t the same as data, and two providers given the same export won’t reconstruct the same depth of “knowing you” from it - that’s a real limitation, not a rounding error, and I think it’s the right one to accept. It leaves room for providers to actually compete on how well they rebuild understanding from what you bring them, rather than mandating uniformity at a layer where uniformity would kill the thing worth having.
Left to the market: what counts as company IP versus your own developed capability. This is deliberately not something I want imposed from outside. Companies should be free to decide how much of their processes, data, and institutional knowledge they’re willing to expose to an AI - and I expect that decision to vary enormously, because it should, and with the AI side being now owned by the employee, even more so. A company that locks everything down protects itself from leakage but forfeits the AI leverage that comes from employees who actually understand their own work well enough to compound it. A company that’s more generous gets more from its people, potentially at real risk. Let that play out competitively rather than legislating a single answer - the interesting effect of forcing companies to actually decide, rather than defaulting to “every digital bit we generate belongs to us,” is that it forces real data classification work that most companies, mine included, have talked about doing for years and rarely finish.
The same classification work settles a second question for free: how much assurance a given role actually needs from its provider. A shop-floor employee running an agent against a maintenance log doesn’t need the same certification tier as a relationship manager whose agent touches customer financial data, and enterprises already know how to make that distinction - it’s the same logic behind tiered physical and system access today. Nothing here needs a single universal bar. It needs the tiering companies already practice, applied to a new category of tool once they’ve done the classification work anyway.
That tiering only works if the tiers themselves map onto something enterprises already trust, rather than a scale someone has to invent. They do. Corporate procurement and legal already trust a stack of existing certifications - SOC 2, ISO 27001, and now ISO 42001 for AI management systems specifically. Any AI provider serious about the enterprise market already needs to clear most of that bar today, which means this isn’t asking companies to vet something alien to their existing vendor risk process - it’s asking them to extend a process they already run and already trust. The portability piece argued above is the actual novel requirement; everything in this section is implementation detail on top of infrastructure that already exists and is already accepted. The certified pool is also larger than “the frontier labs”: hosting providers who already carry these certifications for other workloads can extend them to AI-specific requirements and run the AI-infrastructure for numerous actors, the way mobile virtual network operators lease certified network infrastructure without owning the towers themselves. That widens the field of acceptable providers rather than locking the market to whoever happens to be biggest.
I don’t think this solves the deeper question my earlier piece left open: what should actually count as an employee’s cognitive contribution versus the company’s property, once a system can extract and retain both with something approaching the same fidelity. I think this is a floor underneath that unresolved question, not an answer to it - something that keeps the negotiation possible while the harder definitional work happens, rather than something that lets companies enclose the whole space before the negotiation even starts.
I also don’t know whether an obligation this size can plausibly become policy anywhere, and I’m not pretending the political path is clear. What I do know is that the enterprise-side argument just got a much better vocabulary and a much more credible spokesperson - aimed entirely upward, at protecting companies from their own vendors. I haven’t seen anyone with comparable reach make the mirrored case: not the general “AI is good for workers” or “AI is bad for workers” debate, which plenty of people are already having, but this specific move - taking the boundary enterprises are now demanding for themselves and asking why it stops at the enterprise. That gap is what this is meant to start closing.