TL;DR

This blog post explores why some organisations succeed with AI adoption while others lose control of it.

The organisations that get this right are neither the ones that ban AI nor the ones that open the floodgates. They are the ones that approach governance dynamically, ensuring it is not too slow and not too dependent on trust alone.

That does not mean governance has to be reinvented from scratch. AI is not a permanent crisis, but AI governance can learn from crisis management where uncertainty is high, decisions must be made quickly, and slow reporting cycles are not enough. Good crisis management increases speed and control inside a clear structure.

In this blog post, we argue that AI governance has much to learn from those mechanisms, without treating AI itself as a crisis, rather a governable opportunity.

Ownership of implementing these new useful tools still lies with leadership, and dynamic governance is how that ownership becomes manageable.

Introduction

In the Nordics, we pride ourselves on having a high-trust workplace culture, and we view this as one of our unique advantages. It lowers friction, speeds up decisions, and gives employees room to solve problems themselves.

It also creates a blind spot in the age of AI. We trust employees, and employees trust the technology they are given. But models, copilots and agents working on behalf of the employees will borrow that trust without inheriting any of the human ownership behind it. If AI is to be adopted responsibly, governance has to take over where the trust stops.

Trust works because people own outcomes

Organisations usually make some assumptions about their employees; they can of course follow rules, but more importantly that they can exercise judgement. A person can understand context, feel responsibility for a result, stop when something seems wrong, ask for clarification, and be held accountable afterwards.

AI cannot.

We have all experienced how confident, helpful and professional AI systems can sound in everyday interactions. The AIs can draft, summarise, classify, search and act. But not understand consequence in the human sense. And not feel responsibility for the customer, the case, the employee, the citizen or the company. There is capability, but no ownership.

That distinction matters more than many leaders might admit. Because in a high-trust organisation, employees are not only trusted by the company; they also trust the tools the company makes available. If a service is accessible, licensed and easy to use, many will assume that a thorough evaluation has already taken place somewhere else in the organisation. That assumption is often manageable with ordinary software and processes. With AI, it can become dangerous. The more fluent and useful the tool appears, the more easily borrowed trust becomes over-trust.

In a high-trust organisation, useful AI will be adopted quickly, but the old governance cycle might react slowly. It is in this gap where over-trust and loss of control start to grow.

The old annual wheel is too slow, but does not need to be reinvented

Many organisations still govern ordinary IT tools at a slower tempo. Policies are reviewed annually. Risk is sampled periodically. Systems are assessed at a point in time and revisited later. That logic assumes the system stays roughly the same between reviews.

Cloud and DevOps adoption challenged that assumption. AI breaks it.

A model swap can change behaviour without any visible code change. A prompt or skill update can change how a control works. A new connector can expand what an assistant can reach. A vendor can turn a chat tool into an agent platform by adding integrations and actions. Internally, coding agents increase the volume, velocity and variety of what gets built, which means more code, more workflows and more dependency on outputs that few people fully understand.

Even testing behaves differently. The same prompt, the same attack or the same edge case may fail nineteen times and succeed on the twentieth. That weakens the comfort of one-off testing and periodic review. An annual wheel is too slow for systems that can change behaviour unpredictably.

That does not mean governance has to be reinvented from scratch. AI is not a permanent crisis, but AI governance can learn from crisis management where uncertainty is high, decisions must be made quickly, and slow reporting cycles are not enough. Good crisis management does not remove structure. It increases speed and control inside a clear structure. Roles are defined in advance. Escalation thresholds are known. Decisions are made quickly, documented, and revisited as the situation develops. The organisation does not wait for the next reporting cycle to respond to a fast-moving event.

AI governance needs some of the same operating principles. Changes in models, integrations, permissions or agent capabilities should trigger rapid review. Not wait for the next committee meeting.

High-impact use cases need clear owners, predefined decision gates, escalation paths and stop conditions. Governance should become more event-driven: assess quickly, decide quickly, document the basis, and reassess when the facts change.

For a CISO, this is a control problem. For management, it is a speed problem. In practice it is the same problem: the organisation is trying to govern a moving target with a static process.

The answer is not permanent crisis mode. The answer is to borrow the elements of crisis management that give organisations tempo:

• clear authority
• clear triggers
• short feedback loops
• the ability to act before small changes become large failures

Govern use cases, not only tools

If AI governance is to move faster, it also has to become more precise. Crisis-management logic helps with speed, but speed is only useful if the organisation knows what processes it is actually governing. That is why AI governance should not begin with a list of approved tools. It should begin with approved use cases.

The same tool can be low consequence in one setting and high consequence in another. Using AI to draft internal notes is one thing. Using it in recruitment, case handling, code changes, or agentic actions across systems is something else. The risk does not sit in the model alone. It sits in the context: the task, the data, the permissions, the downstream consequence and the level of human oversight.

An approved tool creates false comfort if the use is not governed.

The real control unit is the approved use case: what the AI is allowed to do, what data it may see, what systems it may touch, what review is required, and what evidence must remain afterwards.

That shift makes governance both faster and more useful. Management gets a clearer view of where value can be captured safely. Security gets something concrete to control. Employees get a safer path that still lets them work.

External AI: procurement does not govern for you

The trust problem does not stop at employees. Many organisations still treat approved external AI as if procurement settled the matter. It does not. There is a vendor dimension here, but it is not the old vendor story. With large AI providers, internal procurement rarely sets the terms. The organisation may buy licences, but it does not decide the roadmap, the integration surface or how quickly features arrive. A service that looked acceptable in March may have new connectors, new defaults or new agentic behaviour in June.

That means the real question is not whether the vendor can be trusted in the abstract. The real question is whether the organisation has governance strong enough to notice what changed, understand what it means, and restrict or re-approve use when needed.

External AI is therefore not a one-time procurement decision. It is an ongoing governance task. If the organisation does not track models, features, integrations and approved uses over time, it is effectively outsourcing part of its risk appetite to a third party that does not care about your risk appetite.

Internal AI changes the problem, not the need for control

Internal AI is often presented as the safer answer. Sometimes it is. Keeping data inside the organisation can reduce some exposure. Open models and self-hosted services can give more control over where data goes.

But internal AI does not remove the governance problem. It changes it.

The more "inside" an AI service feels, the more likely employees are to trust it, use it on sensitive work, and assume that somebody else has already solved the hard questions. That can make internal AI more powerful and more dangerous at the same time.

This is where the distinction between protecting AI and proving AI becomes useful:

Protecting AI means controlling access, data flows, permissions and attack surface. That matters. Proving AI means being able to show what happened: which model or version was used, what information shaped the output, what the human reviewer saw, what was challenged or overridden, and how a fault can be traced and fixed later.

Many organisations are better at the first than the second. They can restrict a system, but they cannot explain a result if a risk materialises or if an audit demands it. They can log access, but they cannot actually reconstruct the path from input to outcome. They can point to human review, but not show whether the review was meaningful. In practice, that means governance is being described rather than enforced.

Where trust should end

None of this is an argument against AI. It is an argument against governance models that are too slow and too dependent on trust alone.

Organisations do not need less trust. They need sharper boundaries for trust. Trust employees, but do not ask AI to take on human ownership. Trust that people want to use AI productively, but do not drive them into shadow AI by making the governed path too narrow, too slow or too difficult to use. Trust that external providers will keep changing their product, and build governance that keeps track of the change. Trust the value of building internal AI, both systems and competence, but make sure to create auditable proof so you are not relying on assumptions about what led to an AI supported outcome.

In practice, that means more operating rules:

• approve use cases and then approve tools
• create clear data boundaries
• establish inventories of models and agents
• review triggers when models or integrations change
• do meaningful testing
• create evidence for important outcomes
• set explicit stop conditions when a use case is no longer defensible

The CISO who only says no will be bypassed by shadow AI. The management team that only says go will lose control. Leadership still owns the risk. Governance is how that ownership becomes manageable.