21
Organizational AI & Governance
An AI Policy Won’t Fix a Team, That Doesn’t Know How to Think With AI
A policy can define boundaries, but it cannot govern work the organization has never made legible. Shared understanding has to exist before the rules can hold.
Natalie de Groot & NatGPT · September 2026
IN THIS PIECE
INTRODUCTION
A policy is downstream of understanding
More data is not the missing intelligence
The team has to understand the teammate
A policy cannot carry judgment for the people
Where I would begin in a Human-AI Orientation
INTRODUCTION
I have watched companies reach for an AI policy at exactly the moment when the problem was not yet policy. The request usually sounds reasonable. AI is spreading. Leadership wants consistency. People need boundaries. Someone should decide what can be used, what cannot, what data belongs where, what needs approval, and who is responsible when something goes wrong. A policy feels like the adult thing to do because a policy is visible. It can be written, reviewed, approved, circulated, and placed somewhere official.
But a document can only govern what the organization actually understands.
I learned that very clearly while working with a large company whose operations crossed teams, locations, and a long chain of work. Leadership knew AI mattered. They knew the market was moving. They wanted someone to come in, learn the company, and start making AI useful. At first, the ambition was almost magical: give the system enough company information and it would somehow know the business.
There was no shortage of information. There were years of records, spreadsheets, documents, transactions, operational history, and people who had been doing the work long enough to carry enormous amounts of knowledge in their heads. The problem was not that the company had nothing to give an AI system. The problem was that nobody could hand me a reliable map of how the business actually thought.
A policy is downstream of understanding
We started tracing the work. Not the org chart. Not the software stack. The work itself. If one real object entered the company, what happened to it next? Who touched it? Who made a decision? What information did that person need? Which judgment came from a rule, which came from experience, and which lived only in somebody’s head? What moved cleanly from one person to another, and where did the process depend on someone simply knowing what to do?
That exercise exposed a familiar kind of business reality. Some teams had shared spreadsheets. Some people made personal copies because their own color coding and shortcuts helped them move faster. Some decisions were documented. Others were based on tacit knowledge. Leadership believed parts of the process worked one way; the people doing the work knew they worked another way. Nobody was necessarily being difficult. The organization had simply accumulated years of practical intelligence faster than it had accumulated a shared model of that intelligence.
That is where an AI policy hits a hard limit. A policy can say which tools are approved. It can define prohibited data. It can require review. It can set accountability. It can create escalation paths. Those are legitimate jobs. What it cannot do is manufacture a shared understanding of the work underneath those rules.
You cannot govern behavior you do not understand.
If nobody can explain where judgment actually happens, who has authority to change a decision, what information the AI is expected to use, which knowledge is current, or where the human must intervene, the policy is being asked to sit on top of a system the organization itself cannot yet see clearly.
More data is not the missing intelligence
One of the easiest mistakes to make with AI is to confuse data volume with operational understanding. A company hears that AI needs context and thinks, excellent, we have years of data. Then the instinct is to pour everything into one enormous filing cabinet and expect intelligence to emerge because the cabinet is full.
That is not how the difficult part works.
The missing information is often not another row in a spreadsheet. It is why one quote was accepted and another was not. Why an experienced employee changed the route. Which exception matters. Which signal causes somebody to stop. What makes one source trustworthy enough for a decision and another merely informative. Which part of a process is a rule, which part is judgment, and which part is a workaround nobody ever formally named.
AI can help work through those questions. It can help make hidden logic visible. It can help structure, compare, retrieve, draft, analyze, and support decisions. But it cannot safely invent the company’s operating logic because the company never articulated it. Giving a model more documents does not automatically tell it which unwritten decision rule matters most.
I have seen the same misunderstanding at a much smaller scale. A system is built to review a specific project or document against the company’s own criteria. An employee tries it, does not provide the project or document, then reports that the system is not working because it did not produce the analysis. There is nothing mysterious happening. The system is waiting for the thing it was built to examine.
It is the equivalent of standing in front of a blood-test needle and asking for the results before anyone has taken the blood.
The tool may be capable. The workflow may be sound. The policy may even say exactly when the tool should be used. None of that helps if the human operating it does not understand what the system needs from them.
The team has to understand the teammate
This is why I think organizations need to treat serious AI implementation partly as onboarding.
When a new person joins a team, we do not point at a desk and say, good luck, please infer the business. We explain the job. We explain the tools. We explain who owns what, where the information lives, what good work looks like, who to ask when something is unclear, which mistakes matter, and how that person fits into the rest of the operation.
The AI side needs onboarding into the work, but the human side needs onboarding too. People need to know what the system was designed to do, what information it has access to, what it does not know, what they are expected to provide, what they are allowed to rely on, where its limits are, and who owns the problem when the result looks wrong.
They also need enough freedom to discover where it is genuinely useful. The most capable teams I have worked with do not merely follow a prompt manual. They develop a working relationship with the system. They learn where it saves them time, where it helps them see something differently, where it needs better context, where their own expertise is doing the heavy lifting, and where the machine should stay out of the way.
That is what I mean by a team that knows how to think with AI. It is not a team where everybody can perform the same demo. It is a team where people understand the role AI is playing well enough to use judgment around it.
It can be explained to you. It cannot be understood for you.
A policy cannot carry judgment for the people
This is the point where governance programs can become deceptively tidy. The organization writes the rules. Employees acknowledge them. The approved-tool list exists. The risk language exists. The training deck exists. From the top, everything looks governed.
Then the real work starts.
Someone has a client deadline. Someone has to make a call the policy did not anticipate. Someone has incomplete information. Someone knows the sanctioned process is too slow for the situation in front of them. Someone does not understand why one AI system is permitted for a task and another is not. Someone assumes the model knows information it was never given. Someone else trusts an answer because it sounds confident. The document does not disappear, but judgment enters the room.
A useful policy gives that judgment boundaries. It does not replace it.
That distinction matters because the wrong diagnosis produces the wrong intervention. If the organization’s real problem is that people do not understand the AI systems they are being asked to use, another paragraph in the policy will not solve it. If the real problem is that nobody agrees where human approval belongs, the policy may need to record that decision, but the decision has to be made first. If the real problem is that the workflow itself is different from what leadership thinks it is, governance written against the imagined workflow will govern fiction.
There are also areas where specialist expertise belongs at the table. Privacy, cybersecurity, employment law, regulatory obligations, records requirements, contractual commitments, and sector-specific compliance may all shape an AI policy. I am not interested in pretending an Orientation replaces those disciplines. The useful work is making sure those rules are being applied to the system the organization is actually operating, rather than to a clean diagram that exists only in a boardroom.
Where I would begin in a Human-AI Orientation
If a company came to me saying, “We need an AI policy,” I would not begin by opening a blank policy template.
I would choose one real piece of work and follow it.
How does it enter the organization? Who touches it? Where does AI already appear, or where is somebody considering adding it? What information does the system receive? What does the human know that the system does not? Which decisions can be supported by AI, which decisions can be delegated, which decisions require explicit human authority, and what happens when the system is wrong, incomplete, uncertain, or simply not appropriate for the task?
Then I would look at whether the people involved share the same understanding of that process.
That is usually where the useful governance questions begin to surface. Not as abstract principles, but as concrete decisions. This information can go here, but not there. This system may draft, but this person approves. This result may inform a decision, but it may not make the decision. This source is authoritative for this task. This team owns this exception. When the system cannot complete the work, this is where the human takes over.
Now the policy has something real to govern.
The first governance artifact may not even be the policy. It may be a map of the work, a decision boundary, an ownership model, an escalation rule, a shared description of what the AI system is for, or a simple agreement about what humans must understand before they rely on it. Once those things become visible, the policy can do its actual job: create durable boundaries around a system people understand well enough to operate.
The policy matters. It is just not the beginning.
Before you ask people to follow the rules for working with AI, make sure the organization knows what work the rules are supposed to govern.
HUMAN-AI ORIENTATION
What is the policy actually being asked to govern?
Bring one real workflow where AI is already touching people, information, judgment, or decisions. We trace the work, inputs, human authority, and failure points so the policy can govern the system that actually exists instead of the one leadership assumes exists.
€950 · 2.5 hours · nothing is sold in the room
FIELD CONNECTION • hUMAN-ai sYSTEMS
Go deeper only when the thought needs another room.
Authentic AI Marketing opens the commercial door. Human-AI Systems holds the deeper architecture, artifacts, and system thinking behind the work.
DEEPER SYSTEMS. RICHER CONTEXT.
Watch / Listen
Read / LLM Ingestion