Chapter 7 — The Bargain for Workflow Data and Context
Consider a maintenance-AI project. Work orders, operating logs, and calibration data created while engineers handle equipment failures may become material for improving an internal system. Engineers may record causes when faults occur; those records can inform later review and training. Yet the project can still omit the sentence addressed to the engineer: while repairing equipment, that engineer is also producing data the organization may reuse. The organization needs to explain that plainly.
This is the layer leaders often miss. AI does not learn only from company documents. It learns from how employees work: how customer service recognizes that a customer is about to explode, when sales should stop pushing, why an HRBP pauses over a résumé, or why an engineer skips the first two steps in a manual during a fault. What used to be called experience can become a training asset. Work orders, annotations, edit histories, communication traces, operating paths, and review comments were once merely process records. Once they can be structured and used for training, they raise a different question: whose experience is this?
For an organization, the opportunity is obvious: personal experience may become organizational capability. For an employee, it can feel like this: the company is learning what I know and may later use it to replace me. That is the data-contract problem of the AI era. If it is left unexplained, organizational learning can feel like a change imposed without warning. Employees may comply without offering the judgment that matters.
The Process Is Not the Same as the Output
Companies have long assumed that work products belong to the organization: reports, orders entered, code submitted, and work orders completed. AI pushes the boundary earlier. It wants to learn not only that a senior engineer fixed a machine, but why the engineer checked one sensor first, departed from the manual sequence, or recognized that an alarm code pointed to operating habits in the field rather than a faulty component. Likewise, an HRBP’s recommendation is an outcome; the reasoning about team fit, risk, and whether an “urgent hire” actually reveals an organizational-design problem is part of the process.
Outputs are comparatively easy to assign. The process contains tacit judgment, personal style, experience paths, and risk intuition. Once that process is recorded, structured, and used for training, “it is all work data” is no longer an adequate answer. Look at the AI-system plan already being built: does it collect outputs, or does it collect process? If it collects process, the question is not a legal wording exercise alone. It is a foundation of organizational trust.
A Contract Is More Than Consent
Many companies hear “data contract” and think of a legal document, a privacy-policy clause, or a confirmation screen. Those measures may exist, but they are not enough. A contract for employee workflow data must explain what the company collects, who can see it, how it will be used, what employees receive in return, and who is responsible when something goes wrong. Without clear answers to those five questions, consent is only a formality.
Employees will ask more pointed questions. Will the judgment I contribute become evidence used to eliminate my role? Will my process data be used by my direct manager in performance evaluation? If AI learns from my experience and makes a mistake, will that mistake be traced back to me? When the organization leaves these questions unanswered, people protect themselves: work orders become safer, retrospectives become emptier, and important judgment remains in their heads. The organization thinks it has captured data; it has captured noise.
The answer is a contribution bargain, not a request for loyalty. The organization asks people to make the real work visible: the exception, the workaround, the judgment that prevents an avoidable failure, and the correction that makes an AI-assisted process safer. In return, it must make five commitments visible in the operating arrangement: purpose, boundary, attribution, return, and correction. The terms can differ by company and by workflow. The five questions cannot disappear merely because a data-collection notice exists.
Purpose means naming the decision the material is meant to improve. “Improve AI” is not a purpose. “Help service representatives recognize the three conditions that require an immediate escalation” is a purpose. Boundary means distinguishing material that may support search or process improvement from material that should not migrate into training, evaluation, or a different workflow without a fresh explanation. A contribution bargain that cannot name its use is asking employees to transfer judgment into an unknown system.
Attribution means recording the contribution as work rather than treating it as free residue of a normal job. This is not a claim that every contribution creates individual ownership of a company asset. It is a management choice to make valuable process repair, exception discovery, and reusable judgment visible in the same way the organization makes other valuable work visible. A contributor should be able to see what was captured, the workflow to which it was attached, and the person responsible for keeping it current.
Return means the contributor has a credible place in the better workflow that their contribution helps create. It may include recognition in performance and development, participation in redesign, a role that emphasizes exception judgment or knowledge maintenance, or a clear explanation of how standard work will change. It is not a promise that every role remains untouched. It is a refusal to treat the people who expose the real work as disposable inputs to an efficiency program.
Correction means that a person who contributed experience is not automatically made responsible for every later output derived from it. The process owner, review owner, and accountable executive retain the responsibilities and decision rights appropriate to the live workflow. Contributors need a route to flag a misuse, outdated rule, or misleading interpretation without having to defend themselves after an incident. Otherwise the organization will collect sanitized descriptions and call them knowledge.
The bargain has to survive a difficult case, not just a launch announcement. Suppose a service representative explains the phrasing that signals an imminent complaint. The team turns that observation into a routing cue. Six weeks later the cue sends an ordinary request to an escalation queue. The question is not whether someone can blame the representative for an imperfect rule. The question is whether the team can inspect the source, correct the cue, update the workflow, and show that the correction reached the next shift. A system that cannot do this has collected context without building a responsible way to use it.
Separate Four Kinds of Data
Employee work data should not be swept into one bucket. First, work-output data—documents, code, work orders, project materials, and customer records—are organizational outputs, although their intended use should still be stated: search, process improvement, or internal-model training. Second, workflow data—operating paths, edit trails, communication records, review comments, and approval habits—are more sensitive because they approach a person’s way of judging. Third, evaluation-related data—performance conversations, capability assessments, promotion discussions, talent reviews, and hiring-screening opinions—can immediately raise concerns about an employee’s future position. Fourth, highly sensitive data—health, compensation negotiations, private circumstances, and trade-union or labor-relations material—should not be used casually for AI training merely because technology can access it.
Before scaling, the CEO, chief human resources officer (CHRO), CIO, and the accountable executive for the affected process should review each category together. For each one, ask: how will employees understand its entry into the system, can the organization explain it, and who is responsible if something goes wrong? That produces a meeting-ready list rather than a technical field catalog.
Transparency, Then Consent
The first layer of a data contract is transparency. Employees should be able to find five things at any time: which systems collect their workflow data, which AI use cases rely on it, who has access, how long it is retained, and who notifies them when the purpose changes. Transparency is not a companywide announcement. It is an accountable management responsibility. The less clearly the boundary is visible, the more cautiously employees will act—and the less real experience the organization will learn.
Only after transparency comes consent. Knowing is not agreeing. Work-output data may enter an organizational knowledge system by default when its purpose is clearly stated. Workflow data require a scenario-specific explanation: why a customer-service flow, maintenance work order, or campaign review collects it; how it will be used; who can see it; and how an employee can give feedback. Evaluation-related data require greater restraint: in hiring, performance, promotion, and employee evaluation, people must retain judgment and the organization must retain a review mechanism. Highly sensitive data should, as a principle, stay out of training. A generic consent form should not be asked to answer four different data questions.
The Risk Runs Both Ways
The organization is not the only party that can overreach. Employees can also put organizational data into external AI tools. When the company provides no useful tool, approval takes too long, IT is still evaluating, security says no, and the business team needs to deliver today, a frontline employee may open a personal account and paste in customer material, meeting notes, project plans, candidate résumés, or internal data.
Unauthorized use can be an organizational symptom when formal channels cannot keep up with employee needs. The employee may be trying to complete the work, but organizational risk has already occurred. This is a management diagnosis, not a claim that every employee or company behaves the same way.
That is why a data contract must address both boundaries: how the company collects employee workflow data, and how employees may use AI with work content. The first protects employee trust; the second protects organizational assets. A ban without a practical, fast, usable route drives use underground and removes the organization’s ability to see what is happening. Before issuing a prohibition, spend a week finding out how much work is already completed through personal accounts.
Benefit Answers “Why Should I?”
Even when employees know and agree, they will ask what they receive. If people contribute high-quality judgment, AI learns it, and the organization becomes more efficient, an answer of “nothing”—or a later role reduction—will make them less willing to contribute again. The organization must discuss benefit, not only contribution. Benefit need not be direct payment; it may take the form of role upgrading, performance recognition, project opportunity, and career expectation.
An engineer who captures complex fault-diagnosis experience should not be treated as simply replaceable once AI handles standard questions. The person may move toward exception review, knowledge stewardship, or field-problem expertise. An HRBP can contribute a candidate-judgment framework while AI performs information organization and risk flagging; cultural fit, trust potential, and organizational-risk judgment still remain human work.
The exchange must be visible. Contributions that create reusable judgment, correct an AI error, or stabilize a process should be recognized. Do not ask employees to “contribute data assets” for a vague organizational capability program. State the exchange plainly: the organization will retain useful experience so new employees make fewer avoidable mistakes and repeated problems occur less often; employees’ judgments and corrections will be visible; and as AI takes standard actions, employees should move toward higher-value exception judgment, process maintenance, and system training. Without a new place for the contributor, do not pretend this is shared growth.
Responsibility Answers “Who Carries the Outcome?”
When AI uses employee data and gets a judgment wrong, responsibility should not automatically be pushed onto the person who contributed the data. That person contributed experience in a particular setting; they did not necessarily decide how the system was designed, where it was used, or how its final output was reviewed. A responsible person has authority, information, time, and a way to correct the course before the incident. A scapegoat is identified afterward.
The contract therefore needs five named answers: who decides collection, who decides purpose, who is responsible for system design, who performs routine review, and who is responsible for the final business outcome. If these questions are not answered before launch, the organization will pass responsibility around after an incident. A human click is therefore not, by itself, a complete accountability loop.
The five questions themselves are a management action, not a research finding. Without information, time, authority, and a means of correction, human confirmation is a rubber stamp and the design of the organization still bears responsibility. Where the mechanism is incomplete, someone must be willing to take responsibility before the error passes downstream.
Put the Contract on One Project This Week
A meeting question such as “Have we handled employee-data compliance?” produces little. It lets legal and IT say that consent was signed and the process is complete while leaving transparency, consent, benefit, and responsibility untouched. Ask instead: what employee workflow data are being collected; are they used for search, training, evaluation, process improvement, or business decisions; can employees know, inspect, and give feedback; how are high-quality contributions recognized and amplified; and when AI output based on these data is wrong, who corrects it, reviews it, and is accountable for the final result?
Do not start with a companywide rollout. Select one AI project. List its work-output, workflow, evaluation-related, and highly sensitive data. For each category, specify purpose and access: who can see it, how it can be used, how long it is retained, and whether a changed purpose requires a renewed explanation. Then add a benefit-and-responsibility statement: how a contributor’s judgment will be recognized, and who reviews, corrects, and carries the result when AI output is wrong. If those three things cannot be stated, the project is not ready for scaled deployment. Explaining the exchange is not cosmetic; it is how the organization continues to receive real experience.
Run this as a working conversation with the people closest to the flow, not as a document sent after the design has been settled. Show the proposed data path on one page: where the material begins, what the AI-enabled step uses, what is retained, who can inspect it, and which decision it may influence. Ask participants to mark the point at which the path becomes misleading, intrusive, or unsafe. Their answers may change the design: a useful route for troubleshooting may be inappropriate for performance evaluation; a retained exception may need a shorter review cycle; a high-value judgment may need a named knowledge maintainer before it is reused.
The result should be a project-level record with three linked parts. The first is the data boundary: categories, stated purpose, access, retention, and change trigger. The second is the contribution record: what judgment, correction, or context was made reusable, where it appears in the workflow, and how it is attributed and maintained. The third is the accountability route: who can question the use, who reviews a disputed interpretation, who can correct the process, and who remains accountable for the business consequence. Keeping these together prevents an organization from treating data collection as a technical detail and the people consequences as a later communication problem.
The manager’s test is simple. Can an employee explain, in plain language, what the project is learning from the work, what it will not learn, why the distinction matters, and what happens when the system gets the context wrong? If the answer depends on a policy lawyer, a system architect, and a different manager each telling part of the story, the bargain is not yet operational.
This clarity also improves the system itself. A team that can state its intended use and boundary can test whether new data, a new model behavior, or a proposed role change has pushed the project beyond what participants understood. It can pause the changed use before it becomes a silent expansion of purpose. The contribution bargain is therefore not a communication layer placed on top of the work. It is one of the mechanisms that keeps organizational memory useful, bounded, and accountable as the workflow changes.