You know the scenario. An AI project starts with enthusiasm. The early demos win over the leadership team. Then the questions come from legal. Or the data protection officer gets in touch. And suddenly everything stalls.
For many organisations, governance is what turns an exciting digitalisation project into a compliance exercise. Something that needs to get done eventually, but please not until the essentials are in place.
I consider that the most expensive misunderstanding in digitalisation. Not because compliance rules are particularly exciting. But because the moment you try to retrofit governance is almost always too late.
The problem: governance as an afterthought
A manufacturing company introduces a new ERP system. Eight months of project duration, significant budget, an ambitious team. Just before go-live they discover: supplier data is structured differently across three separate systems. The analytics module they chose requires risk classification under the EU AI Act. And nobody has defined who is allowed to see which data.
The project stands still. Not because the technology failed. But because the architecture was never settled.
Learn what matters. Unlearn what holds you back.
Then there is a second variant of this problem, subtler, but equally expensive.
Some organisations do have governance. It is just written for a different time. Guidelines from 2018 that do not even mention the word "AI". Approval processes designed for a market that changed quarterly, not weekly. Data protection concepts that are airtight on paper and that nobody reads in reality.
The rulebook exists. But it has not grown with the organisation's innovation path.
What follows? Often a quiet practice: old rules are formally maintained while being operationally bypassed. Apparent compliance. Everything documented, nothing actually valid.
In that situation, adding new rules is the smaller problem. The larger one is letting go of old ones. Processes that once made sense but now generate effort without protection. Approval loops too slow for the pace of AI adoption. Security concepts still referencing on-premises infrastructure while the organisation has long since moved to the cloud.
Governance that does not learn prevents learning. That is the real handbrake, and it does not look like one at first glance.
The pragmatic solution: governance as an architecture decision
What if governance were not the last thing you build into a project, but the first?
Think-First means: before a technology is selected, before a vendor is commissioned, we settle the architecture. That includes: what applies today, what is outdated, and what needs to be newly decided.
Target picture before tool selection. Which data do you need, and for what? Who decides what? Which systems must talk to each other, and which ones should not?
Review existing guidelines for relevance, actively. Not everything that was once agreed is still worth protecting today. What no longer fits reality should be updated, not silently ignored.
Build in risk classification early. The EU AI Act requires it anyway. Those who classify early have no extra work. Those who do it retrospectively have an expensive problem.
Guidelines should describe what is already lived. The best governance documents emerge from dialogue, not from a desk. They capture how the organisation actually works, not how it ideally should.
A concrete example
A logistics company in German-speaking Switzerland wants to use AI for route planning. Before any system is evaluated, we clarify: which data is being processed? Who may access driver data? What happens if the system fails? And: which existing data protection rules still describe the right reality, and which no longer do?
That takes two workshops. Afterwards the company has not only a basis for the tool selection decision. It also has the foundation for EU AI Act compliance, for the internal rollout, and a governance document that the team will actually use.
No expensive rework just before go-live. EU AI Act, ISO 27001 and DSGVO become part of the architecture rather than a retrospective obligation. Outdated guidelines surface before they cause a project stop. And the team knows what it is allowed to do and can act accordingly.
Conclusion
Governance is not what slows your project down. It is what makes your project fly.
But only if you are prepared to treat it as an architecture decision, not a documentation task. And sometimes that means letting go of old rules that have done their job.
Learn what matters. Unlearn what holds you back.
*(AI generated)*