Your dark data is in the middle of the process

I spent an hour recently in a closed-door session with IT and transformation leaders from banking, manufacturing, and facilities management. I went in expecting a conversation about infrastructure. I left thinking about visibility.

Everyone in that room had modernized something significant. Data centers lifted into the public cloud. Core banking technology moved off premises. ERP consolidation underway across multiple inherited systems. And every one of them described the same thing afterward: the systems changed, and a large share of the actual work did not.

One leader described it directly. You run the best cloud infrastructure available, and your branch and back-office teams are still heavily reliant on manual and paper processes. A manufacturer in a regulated industry pointed out that his products do not leave the building without printed documentation that has to be correct for every country they pass through. The document is generated in the cloud. It ends up on a clipboard.

The infrastructure modernized. The work stayed where it was. And what nobody has visibility into is everything that happens in between.

Dark data usually gets defined as information a business consumed once, then stored and never used again. An invoice in an archive. A PDF on a shared drive. A scanned form attached to a closed case. That definition is correct, but far too narrow.

Take a work order. One system generated it. An employee corrected a field. Someone approved an exception. Data arrived from an ERP. The document was printed, signed, scanned, and sent somewhere else. Someone understood why each step happened and what to do when the standard path failed.

The organization may still hold the final document while losing much of the context around it: who touched it, what changed, which approvals it passed, which systems contributed, and why the work took that path at all.

We record the beginning of a process and the output of a process. The valuable dark data is all the things happening to it in the middle. That middle is where much of the work actually occurs, and it is where visibility ends.

On a slide, modernization is clean. Move the application. Consolidate the ERPs. Replace the legacy platform. In practice, it turns into a Tetris game of systems, people, culture, and twenty years of accumulated decisions.

I have run that play many times. The honest result is that even when the migration succeeds, the net gain is smaller than the business case promised, because the output of that system still flows into the same place it always has. Faster to generate. Same destination. Same document, inbox, printer, or manual handoff waiting at the end of it.

One participant pushed back on the entire framing, and he was right to. The assumption that legacy is bad does a lot of unexamined work. Technology problems are frequently symptoms of organizational complexity rather than causes of it. So the useful question is not which system to replace. It is narrower than that.

Where does the work become invisible?

Sometimes the answer points at a platform. More often it points at a workflow, an integration, intelligent document processing, or one stubborn handoff. Modernize the part that makes work visible before deciding the whole environment needs rebuilding.

The cost of invisible work becomes obvious when the people holding it leave.

One leader described a single year of cost reduction that removed a significant share of his longest-serving staff. Most had a documented role. All of them did additional work that quietly kept the business running, and none of that work was written down. The knowledge left with the people. Months later, the organization is still reconstructing what its own processes are.

The failure mode is specific, and I have watched it in several organizations. Someone leaves an accounts payable function. Weeks later suppliers start asking where their money is. The purchase orders were sitting in an individual inbox, marked ready to send, never sent. The email system did not fail. The organization never made the state of the work visible, and never built a control that survived the person performing it.

People compensate for that gap extraordinarily well. We are superhuman, context-driven creatures. After years in a role, you know which step comes next, which exception is real, and which rule bends. Then the person leaves, or the organization decides an agent should take part of the role.

All that context has to come from somewhere.

An agent without that history is not inheriting an experienced employee’s judgment. It is starting the job without the information that made the employee effective. Models extract, classify, summarize, and decide across documents very well. They do not reconstruct years of unwritten judgment from a final PDF and a handful of fields.

The data backs up how common this is. Nasuni’s State of Enterprise File Data Annual Report 2026 found that 97% of organizations have deployed or are piloting AI agents, but only 18% have deployed them at scale. Fifty-seven percent of AI projects are not delivering their objectives.  Separately, a 2026 BARC study found that 70% of respondents say less than half of their unstructured data is discoverable and usable for analytics or AI.

AI is also not automatically the right answer, and I say that as someone whose teams build with it constantly. New systems introduce new risks. Security posture, scalability, and homegrown components nobody has stress-tested are all part of the trade. A process frequently needs robotic process automation, intelligent document processing, or a well-built API instead. Predictable steps should stay deterministic. Where a probabilistic tool adds real judgment, deterministic constraints still govern what it does, when it stops, and when a person steps in. That is what governance actually means.

One leader in the session kept returning to a single question, including about the thesis I put in front of the group. Why? What organizational capability does this create? Technology is an enabler, not a starting point. Automate a process that is not worth running and all you have built is a faster bad process.

It is the right question, and it is the one I would ask a vendor too.

One of the leaders in the session put the question directly: where do you even start? Here is where I would.

Nearly every application ever written has File > Print, and I have never found one that doesn’t. I have also never had to explain that button to anyone, at any age, at any level of an organization. No training. No adoption curve. No hundred-page manual.

Now treat that click as the start of a process rather than the end of one.

The same click can route an invoice, a work order, a tax document, or an email attachment into a managed workflow. The employee does not learn a new application. The document enters a process at exactly the point where it otherwise disappears into a printer, an inbox, or a manual handoff. Once it enters, the context travels with it:

1. Origin. Which system produced it, and who initiated the work.

2. Extraction. What data was pulled out, added, or changed.

3. Decision. Which person or agent acted, and what was approved.

4. Movement. Where it went, where it stalled, and how long it sat there.

That trail becomes a system of context. A record of how work actually happened, available to inform what happens next.

Leaders can see how much work follows the intended path, how much relies on shadow processes, where exceptions cluster, and where human judgment genuinely adds value. They can trace how a skipped form creates a service desk ticket later when someone has to supply the missing information.

Think of it as a replay. No coach reviews the first whistle and the final score and calls that analysis. They watch what happened in between, because that is where the result was decided. Business leaders deserve the same view of an operational document.

None of this requires a big-bang programme. Those consume years, block everything behind them, and routinely fail to deliver the business case they were approved on. Start with one operational document and answer three questions.

Where does it go? Follow it from creation to completion, including every print, scan, inbox, format change, and system handoff.

Where does the record break? Find the first point where you cannot say who acted, what changed, why, or where the work is now.

What context has to survive? Capture what the next person, system, or agent needs to continue the work reliably. Nothing more.

That first broken handoff is where your dark data begins.

Migrating an application changes where work happens. Capturing the middle changes whether anyone knows how it happens. As we hand agents more responsibility, that record stops being a reporting nicety and becomes infrastructure. It cannot keep living in the heads of the people doing the work today, because eventually those people leave, and everything they knew leaves with them.

Pick one document. Map where the record breaks. Book a walkthrough if you want a second set of eyes on it.