Most AI projects do not get stuck on technology. They get stuck on capacity.<\/p>\n
That is a notable observation, because most implementation plans devote the bulk of their attention to technology. Which model, which data, which integration. Meanwhile, the answer to a simpler question is often missing: can our organisation carry what we are already technically capable of?<\/p>\n
The bottleneck is rarely technology. It is governance and learning capacity.<\/strong><\/p>\n That distinction might sound semantic, but it has practical consequences. An organisation that is technically ready for AI but not organisationally ready scales up into problems that only reveal themselves later, by which point they are already woven into daily processes and therefore far harder to fix than if they had been anticipated.<\/p>\n Clear governance begins with something that sounds simple but is often missing in practice: board-level ownership. Not the arrangement where IT handles it, with the occasional update to the executive team, but a member of the management team or board who explicitly ties AI to strategy, values and risk, and actively maintains that link. Without that figure, AI disappears into the organisation’s technology column, and with it disappears the connection to the broader questions raised in the earlier instalments of this series.<\/p>\n There is also a need for what I call ethics and fundamental rights, although the name may vary by organisation. This means a person, or a small body, with the actual mandate to say no when something is technically possible but morally does not fit. That mandate must not exist only on paper. It must already have proven itself in a situation where it mattered, otherwise it is a formality nobody takes seriously the moment things get tense.<\/p>\n And there is a need for process ownership per use case: not only a project leader who guides the implementation and then leaves, but one owner within the line organisation who remains accountable, even after go-live, for how the system behaves in practice.<\/p>\n Taking risk and impact seriously means more than ticking a box on a legal checklist.<\/strong><\/p>\n An impact assessment must answer three questions, not one. The legal question, is it allowed, is the most obvious and is usually the only one asked. But there is also an organisational question, can we carry it, and a moral question, do we actually want this. A system that is fully compliant legally can still damage an organisation that cannot carry it, or violate a value the organisation claims to hold dear.<\/p>\n It helps to explicitly distinguish between two zones. The play-and-learn zone is the space where experimentation happens, with limited risk and room to learn from mistakes without major consequences. The critical production zone is the space where standards, logging, an audit trail and formal oversight and escalation paths are essential, because the consequences of an error there can genuinely be severe. The most dangerous scenario I encounter in practice is a project that starts in the learning zone, with all the freedom that comes with it, and quietly shifts into the critical zone without the corresponding safeguards moving along with it. That rarely happens in one conscious step. It happens gradually, through small extensions that each seem reasonable on their own.<\/p>\n A learning architecture is different from separate training sessions, and the difference matters.<\/strong><\/p>\n A training session teaches people to use a tool. A learning architecture helps an organisation mature in how it handles a new form of power and accountability. That is a different kind of work, and it calls for different instruments.<\/p>\n The first instrument is leadership development through an AI lens: steering in an environment that has suddenly become far richer in data than before, continuing to read the undercurrent even when dashboards suggest everything is under control, and guarding human scale precisely at the moments the system suggests that scale has become superfluous.<\/p>\n The second instrument is a fixed rhythm of reflection. Quarterly conversations with management and key figures from across the organisation, in which the focus is not the technology but the practice: what is actually happening, what side effects do we see, which dilemmas keep recurring? Those conversations should not only take place, they should also genuinely lead to adjustments in processes and frameworks. A reflection conversation that never leads to a change becomes, after a few rounds, a ritual formality nobody takes seriously any more.<\/p>\n The third instrument is learning from incidents. Mistakes and near-misses around AI must become learning data for the system as a whole, not the occasion for a blame question directed at one person. That distinction is crucial, because a culture of assigning blame causes incidents to be hidden rather than shared, and the incidents that yield the most learning are often precisely the ones most tempting to conceal.<\/p>\n What can you do with this today? Label all your existing AI initiatives, without exception, as learning zone or critical zone, and arrange the corresponding oversight before proceeding further. Over a slightly longer horizon, it helps to set up an AI review board, with a real mandate and a fixed rhythm, not as a symbolic body but as a place where decisions are actually made. And what is best avoided is scaling before roles, logging and dissent are secured. Reversing that order is the most common mistake I encounter in practice, and also the most expensive one to fix later.<\/p>\n What is most true for you right now: can we already do more than we dare, or are we already doing more than we can carry?<\/p>\n Both answers call for a different next step. The first calls for courage. The second calls for a pause.<\/p>\n Notes for those who wish to read further:<\/em><\/p>\n It is not technology but capacity and governance that are the real bottleneck for AI. Part four of a series on implementing AI without losing yourself.<\/p>","protected":false},"author":1,"featured_media":1263,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[89],"class_list":["post-5041","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog","tag-english"],"_links":{"self":[{"href":"https:\/\/dbvp.nl\/en\/wp-json\/wp\/v2\/posts\/5041","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/dbvp.nl\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dbvp.nl\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dbvp.nl\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/dbvp.nl\/en\/wp-json\/wp\/v2\/comments?post=5041"}],"version-history":[{"count":1,"href":"https:\/\/dbvp.nl\/en\/wp-json\/wp\/v2\/posts\/5041\/revisions"}],"predecessor-version":[{"id":5104,"href":"https:\/\/dbvp.nl\/en\/wp-json\/wp\/v2\/posts\/5041\/revisions\/5104"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/dbvp.nl\/en\/wp-json\/wp\/v2\/media\/1263"}],"wp:attachment":[{"href":"https:\/\/dbvp.nl\/en\/wp-json\/wp\/v2\/media?parent=5041"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dbvp.nl\/en\/wp-json\/wp\/v2\/categories?post=5041"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dbvp.nl\/en\/wp-json\/wp\/v2\/tags?post=5041"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n