AI Output Is a Boundary Object. That Is Why It Is So Hard to Govern.

I sat in on a meeting last month where a compliance officer and a product manager argued about the same AI generated email. The compliance officer said the email was a company record and needed to be retained, logged, and auditable. The product manager said it was a draft, a starting point for the human editor, and that logging every draft would kill the team's velocity. They were looking at the same text. They were both right. And the organization had no policy that could handle this because it had never asked whether an AI output is one kind of thing or many.

Star and Griesemer (1989) gave us the vocabulary for this problem almost forty years ago. They were studying how biologists, curators, and funders at the Berkeley Museum of Vertebrate Zoology coordinated work despite having different goals and different ways of seeing the world. Their insight was that certain artifacts, what they called boundary objects, are plastic enough to adapt to local needs yet robust enough to maintain a common identity across communities. A museum specimen was not the same thing to everyone who touched it. The biologist saw a data point. The curator saw a training tool. The funder saw an administrative category. Each community interpreted the same physical object differently, but all three could coordinate around it because the object carried a consistent enough identity to be recognizable across groups. The plasticity was not a bug. It was what allowed coordination without requiring consensus.

AI output is a boundary object. A generated text, a prediction score, a recommended action: these artifacts travel across organizational boundaries and are read differently by every department that touches them. Marketing sees a draft to be polished and published within the hour. Engineering sees an output to be evaluated against a prompt, a context window, and a model version, with latency and cost as first order concerns. Compliance sees a record that may need to be retained, explained, and defensible in a regulatory inquiry. Legal might see a liability vector that needs disclaimer language attached. The same string of tokens carries different meaning, different urgency, and different quality criteria in each setting. This is not confusion. This is interpretive flexibility in action.

I keep seeing the same pattern across organizations, and I wrote about part of it before in a post on why enterprise AI governance is so messy. An AI governance policy is written by a compliance team or an AI center of excellence. It defines the output in terms that make sense for that group. The policy says all AI outputs must be reviewed by a human before use, for example. That rule makes perfect sense to a risk manager. It is impossible for a marketing team that generates forty product descriptions per minute, with a human editor who reads each one for tone but cannot possibly verify every factual claim against a source document. The policy gets ignored, or it gets a workaround, and the compliance team discovers the gap during an audit and writes a stricter policy, which gets ignored again. This cycle is so common that most organizations I talk to treat it as inevitable. It is not inevitable. It is a consequence of assuming that an AI output is a uniform object when it is anything but.

This is not a policy design problem. It is a classification problem. The governance framework assumes AI output is a single object type with a single appropriate workflow. But the output is a boundary object, and boundary objects require interpretive flexibility. Each community needs to interact with the same artifact through its own norms, tools, and workflows. The governance framework that works for one community will not work for another, not because the other community is irresponsible, but because the object means something different in that context.

I want to add a distinction that I do not see made often enough in governance writing. An AI model and an AI output are not the same kind of object, and they should not be governed the same way. A model is closer to what Star and Griesemer might call a standardized method: a shared procedure that communities agree to follow, with defined parameters, training data, and validation protocols. A model can be audited in a way that feels stable. A model has a version number. You can test it, you can validate it, you can know what it was trained on. The output of that model, however, is none of those things. The output is what travels. It is what a product manager sees in a dashboard, what a customer service agent reads in a response, what an auditor pulls from a log. The output carries the interpretive flexibility that makes it a boundary object. Governing only the model while treating the output as a trivial downstream artifact misses the entire governance problem. I think this is why so much investment in model auditing produces disappointing results when the same organizations still cannot handle a simple dispute about whether a piece of AI text is a draft or a record.

A colleague asked me what governance would look like if we took the boundary object framing seriously. I think the answer has two parts that seem contradictory but are actually complementary. The first is standardized metadata. Every AI output needs provenance information that tells every community the same baseline facts: what model produced this, what version, what the confidence score was, what data was in the context window, whether a human modified it, when it was generated. I wrote about this in detail in my post on digital provenance as trust calibration infrastructure, because I believe provenance metadata is the structural precondition for any kind of calibrated trust across organizational boundaries. The second part is local interpretation. Each department must be free to treat the output according to its own workflow and criteria. Marketing does not need the same review pipeline as compliance. Engineering does not need the same logging granularity as legal. The metadata provides the shared identity that makes the object recognizable across boundaries. The local interpretation provides the flexibility that makes it useful.

Most governance frameworks I have encountered pick one side or the other. They either impose a uniform workflow that does not match how any department actually works, or they leave interpretation completely unmanaged and end up with no audit trail and no accountability. A boundary object perspective suggests a third path. Standardize the metadata, not the interpretation. Let each community read the output in the way that fits its work, but give all of them the same structured information about where it came from and what its limitations are. The shared identity of the boundary object is maintained not by forcing uniform use but by ensuring a transparent provenance record that everyone can see and rely on.

I do not think this is the only reason AI governance is difficult. The technical challenges are real, and the legal landscape is unsettled. But I think the boundary object problem is the one that governance teams keep stepping over while debating process flowcharts that assume a single object type. The object type is not single. Star and Griesemer told us this in 1989. We should listen.