Every executive team that starts working with AI runs into this question sooner or later: which decision may a system make, and which decision stays with a human. The question sounds simple. The answer often is not, because the boundary does not lie in the decision itself but in what the organization has arranged around it.
There is no fixed list of decisions that must by definition remain human. A dismissal decision, a credit rejection, a medical assessment: these are examples that are often mentioned, but the reason why they are sensitive differs per organization. At one institution it is about legal liability, at another about the irreversibility of the outcome, at a third about the absence of a good margin for error. Whoever copies a list from another organization copies an answer without having asked the question.
What does work is dissecting the decision itself: what is the impact if it goes wrong, can the outcome be reversed, and is there someone who can account for and explain the outcome afterward. These three questions form the basis of what elsewhere are called agent rules: recorded boundaries that determine when a system may continue working and when it must stop and call in a human.
The temptation is great to place this question with IT, as if it were a setting you configure once. That does not work, for a simple reason: an agent rule is only reliable if the organization around it is in order. If nobody knows who owns a process, nobody can determine who the escalation point is. If data are not in order, a system does not know when it encounters an exception that requires a human. The fundamental dimensions of an organization — governance, infrastructure, data management — therefore precede the question of which decisions may be automated. Without that foundation, every boundary you draw is a boundary on paper.
This is also the reason why this question rarely lives in a single place within the organization. The executive board sees the risk, the CIO sees the technical feasibility, the process owner sees the day-to-day practice. How to bring these three perspectives together before the pace of automation becomes a source of disagreement is described in how to hold the pace conversation between the board and the executive team. Whoever asks this question only once the first pilot is already running, asks it too late.
The maturity assessment from hybridresourcing.com maps out whether an organization has the foundation in place to draw this kind of boundary in a meaningful way. Seven dimensions, five levels from baseline to intelligence, and a plotting round in which multiple people score independently of one another. That spread is often the most useful part: if a CHRO puts data maturity at activation and the CIO at baseline, you know a conversation needs to take place first, before a rule is put on paper that nobody can execute.
What the assessment does not do is tell you which decision in your organization may be automated. It measures readiness, not the suitability of a specific task. It tells you whether the organization can carry what AI is capable of, not what AI would concretely take over. That distinction between carrying and taking over is the difference between carrying AI and handing over to AI, and it is a distinction that this page deliberately maintains: a score on the assessment is not a blank check and not a prohibition, it is a snapshot of the state the organization is in at this moment.
That snapshot ages. An organization that scores at foundation for data management today may be at activation a year from now, or may just as well have stayed put. How often it is useful to measure again, and what that depends on, you can read in how often a maturity assessment should be repeated. A one-off measurement that disappears into a drawer has little value; a measurement that restarts the conversation in the executive team does.
The assessment does not resolve the disagreement in your executive team. It makes it visible, and that is not the same thing. If your supervisory board and executive team have already disagreed for some time about the pace of AI adoption, the cause often lies deeper than a lack of facts: it is about risk appetite, about who is held accountable for what, about what happens when someone opens a chat window and thinks they have thereby brought AI into the organization. What you do not see if you only know the chat window is precisely the part of the organization this question is about: the infrastructure, the rules, the people who know when a system must stop. Why your executive team disagrees about the pace is explained on this page, and it is often more useful to have that conversation first than to wait until a pilot stalls and the question comes up anyway.
This page is about the boundary you draw in advance: which decision stays with a human, regardless of what a system can technically handle. Once that boundary is roughly in place, the question shifts to the work itself: which tasks within that boundary are suitable to hand over, and which part of a role remains human work regardless of organizational readiness. The maturity assessment does not answer that question. The work scan from FTE TO AI calculates, per task, which part of the work can be taken over by AI, and thereby connects to the point where this page ends: not whether your organization is ready, but what is concretely on the table to hand over once it is.
The tool with which you can map this out yourself is under construction. Anyone who wants to take the assessment as soon as it becomes available can join the waiting list.
Vraag maar wat er moet staan voordat AI in uw organisatie kan landen.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.