Adopting AI

Before we discuss AI, we examine the processes. Where do delays occur, where is there duplication of work, and where do errors arise?

A bad process remains a bad process – even with AI.

We speak with stakeholders, examine the available data, and evaluate each use case based on impact, feasibility, and regulatory obligations. Simultaneously, we map out your existing AI landscape, including shadow AI – the tools that have long been in use without official approval.

The result is a basis for deciding for or against the use of AI tools.

Target vision, architecture, KPIs, guardrails. And a question that needs to be clarified early on, as much depends on it: What role do you assume?

Anyone who purchases and uses an AI system is an deployer. Anyone who significantly modifies it, offers it under their own name, or uses it for a purpose other than intended becomes a provider – with significantly broader obligations. This threshold is crossed faster than most think: a fine-tuned model, a shared tool, a new use case.

We clarify the role for each system, not globally for the company. And we document what would cause that role to shift.

This is also where governance documents are created: the draft registry entry, the points where human approval is required, and the risk classification. For us, 'Compliance by Design' means it is part of the blueprint, not an addendum.

Depending on complexity and infrastructure, we build either ourselves or with specialized partners. But always with test cases, full logging, and approval points that cannot be technically bypassed.

And with a question that is almost always asked too late in AI projects: Can this actually be used in everyday operations? An approval point that requires three clicks too many will be bypassed – using a secondary account, copy-pasting into a private tool, or through a colleague who has the necessary permissions.

Governance is then merely documented, but not put into practice.

An MVP runs under test conditions. A pilot runs under real-world conditions. With real users, real edge cases, and complications that no one foresaw. That is precisely why this stage holds the most surprises.

This is where what remains invisible in the lab becomes clear: How often does a human actually intervene – and if never, is that due to a good system or just habit? Are the thresholds set correctly, or do they generate so many alerts that no one pays attention anymore? What happens on a Friday afternoon when the interface fails and no one is around?

We measure against the KPIs from Stage 2, test the incident response path in a real-world scenario, recalibrate the thresholds, and train the people who will be working with it.

The result is a rollout decision based on data – not on gut feeling.

An AI system is not a piece of furniture that you just place in the office. Maintaining registries, monitoring models, checking permissions, training people, documenting incidents, evaluating changes – governance is a process with deadlines, responsibilities, and follow-ups.

This is exactly why AI management systems like our AIMS Starter based on ISO/IEC 42001 exist. They turn individual measures into a control loop: setting goals, assessing risks, implementing measures, monitoring, and adjusting in the management review.