AI in the business: how to make a safe start

You are already using AI

Most organisations that ask whether they should start using AI have already started: not through a decision in the leadership team, but through employees who found a tool that made the day easier. An adviser pastes in a draft report to improve the language. A project manager asks a chatbot to summarise a long set of minutes.

It also arrives by another route: as features vendors switch on in software you already run. Meeting notes written automatically, suggested replies in email, summaries inside the case management system. Nobody ordered it. It is simply there one morning.

This is often called shadow AI: use that sits outside the organisation's line of sight. It is rarely ill-intentioned. Usually it comes from people trying to deliver better and faster. But it changes the question. The question is not whether you should adopt AI, but whether you know where it is already in use, and what happens to whatever gets pasted in.

It is also a good place to start, because it turns an abstract argument about technology into something concrete you can act on.

What a language model is, and is not

The tools people use are built on language models. A language model is trained on very large volumes of text and has become good at one thing: predicting what is likely to come next. Everything else it appears to do, such as answering, explaining and summarising, follows from doing precisely that, well, many times over. It is then tuned to follow instructions and be helpful, which is why it so rarely says "I don't know".

Three consequences are worth carrying into a leadership meeting.

It is not a reference work. The model does not retrieve a correct answer from a database. It produces text that resembles a correct answer. Usually those are the same thing. Sometimes they are not.

It makes things up, with the same calm confidence it shows when it is right. The field calls this hallucination. A model can cite a clause that does not exist, a date that is wrong or a source that was never written. It flags none of it, because it does not know it is wrong. It has no internal measure of what is true.

It is agreeable. Push back and it will often change its position. That makes it a poor second opinion and a good sparring partner, but only for someone who already knows the subject.

None of this makes the technology useless. It makes it a drafting tool rather than a source. Anything that leaves the building, informs a decision or ends up as a number has to pass through someone who knows the subject, and that person keeps the responsibility. Accountability does not travel out of the model along with the text.

Why this matters when the information is confidential

When an employee pastes text into an AI tool, that text leaves the organisation. Where it is stored, for how long, who can see it and whether it is used for further training all depend on the agreement you hold with the provider. Free versions and personal accounts usually carry different terms from a corporate agreement, and the free versions are the ones employees find first.

This is where it turns serious for most organisations. A draft dismissal letter contains personal data. A board paper may hold information that should not be known before it is decided. An incident report describes your own weaknesses, gathered in one place.

Personal data in AI tools is a GDPR matter in the ordinary way. You need a lawful basis. You need to know what role the provider is playing: a provider that uses the content to improve its own models is not acting purely as a processor on your behalf. Where the provider is a processor, a data processing agreement must be in place. You need to know where the data ends up, including outside the EEA, and on what transfer mechanism. And the use belongs in your record of processing activities, like any other system.

These are not new rules for a new technology. They are the data protection rules you already have, applied to a new route out of the building.

If it has already happened, and it often has, the answer is not to look for someone to blame. Assess whether it amounts to a personal data breach, document the assessment, and notify the supervisory authority within 72 hours where the breach is likely to result in a risk to the rights and freedoms of the people concerned. Then fix the cause.

Start by seeing what is actually happening

The first move is a mapping exercise, not a project. Ask openly and without sanction: which tools are in use, for what, and how often? Include the features that came bundled with software you already pay for. People will tell you, provided they do not expect to be punished for the answer. That exercise usually says more about your real exposure than a policy document does.

Then comes the decision that belongs to leadership rather than IT: what must never leave? Draw up a short, concrete list. It typically covers:

• personal data on employees, customers and service users
• health data and other special categories of personal data
• board papers and matters still under consideration
• source code and technical documentation
• contracts and bids under negotiation
• security documentation, risk assessments and incident reports

Be specific enough that an individual recognises their own document on the list. An abstract list protects nothing.

Choose uses where mistakes are cheap

Maturity is built where errors can be spotted and corrected without harm. Polishing text you wrote yourselves. Summarising publicly available material. Drafting meeting agendas and internal notes. Ordering your own thinking before a board meeting.

Hold back on the opposite: assessments of individuals, decisions that release money, casework with legal effect, and anything that reaches a customer or a regulator without a person having read it. Not because the technology can never be used there, but because it should go there only once you know how it behaves.

Rules people actually understand

One page is enough. Plain language. Three questions answered: what would you like people to use this for, what must never be pasted in, and who do they ask when in doubt? Guidance that needs legal interpretation does not get followed. It gets quietly worked around, and you lose the visibility you have just acquired.

Make the safe route the easy one. If the organisation provides an approved tool on sound terms and access is straightforward, much of the shadow AI disappears of its own accord. People rarely choose risk deliberately. They choose what works.

The regulation, briefly

The EU AI Act, Regulation (EU) 2024/1689, is risk-based. A small number of practices are prohibited outright. Uses classed as high risk, among them recruitment and employment decisions, creditworthiness assessment of individuals and access to certain public services, carry substantial requirements for risk management, documentation and human oversight. Most ordinary office use falls outside those categories, but nothing falls outside the data protection rules.

Two points tend to surprise leaders. The first is that the obligations reach not only whoever builds an AI system, but also the organisation that puts it to use. The second is the requirement on AI literacy: an organisation must ensure that those using such systems on its behalf have a sufficient understanding of what the tools do and do not do. It is not a demand for certificates. It is a demand that people know what they are holding.

The regulation is marked as EEA-relevant and is expected to be brought into Norwegian law. Whatever the timing, it reaches many Norwegian businesses through customers, owners and suppliers in the EU, who pass the requirements on through their own contracts.

ISO/IEC 42001 is the other half: a management system for artificial intelligence, built on the same structure as ISO 27001: roles, risk assessment, control and evidence. The difference is worth noting. ISO 27001 concerns risk to the organisation's information. ISO 42001 also asks you to assess how the use of AI affects the people it is used on.

Neither is a place to begin; both are places to arrive at. Knowing the direction now simply means not having to undo today's choices later.

The leader's role

You do not need to understand how a model is built. You need to own the strategic choices: what risk is acceptable, which data must never leave under any circumstances, where the value actually lies, and who answers for the use. It is the same role as in any other part of running a business: a capable buyer and a confident scrutineer. Here too, security is decided in the boardroom, not the server room.