Is AI safe for your business?

Yes, with a condition you can check before signing anything. An AI system is safe to use in a business when its failure cases were designed before launch: it has been tested against prompt injection, every decision it makes has a named human owner, and it can be switched off in an afternoon. The demo tells you none of this.

A chatbot our founder built at a different company went live on a working site, with real customer data behind it. Some time later someone probed it with injection attempts, trying to get it to run code and hand over what it knew. It refused, logged the attempt and flagged it for a person.

Nobody was watching the moment it happened. Every check it hit had been written before launch, while the system was still a diagram.

What is safe AI adoption?

Safe AI adoption is the practice of deciding how an AI system should fail before it goes anywhere near a customer. Four questions carry most of it: what data the system can reach, what it is allowed to decide on its own, what it does when it does not know an answer, and who gets told when it gets something wrong. Written answers to those four are what make a system defensible to a customer, to an auditor, or to your own team six months later.

What actually goes wrong when a business adopts AI?

The failures we get called about are dull and they repeat. The system reaches data nobody meant it to reach. It can be talked out of its instructions. It fails without telling anyone.

The second of those has a name and a ranking. OWASP puts prompt injection first in its 2025 Top 10 for LLM Applications: input that alters the model's behaviour in ways the person who built it never intended. It does not have to look like an attack. It does not have to be readable by a human either, as long as the model parses it.

The third costs the most, because nothing alerts you. The agent returns a confident wrong answer, a person reads the confidence rather than the answer, and the mistake is six days old by the time anyone checks.

Underneath all three sits the decision nobody records: which process the tool was bought to fix. Buying before naming it is how a business ends up with an integration it cannot evaluate, because there was never a definition of working.

Is your data safe with an AI vendor?

Only as safe as the terms you agreed to, which is a separate question from whether the vendor is any good.

Three things worth getting in writing before a tool touches customer records: whether your inputs are used to train the vendor's models, how long data is retained and in which jurisdiction, and who inside the vendor can read it. The UK's Information Commissioner's Office publishes guidance on AI and data protection, including a risk toolkit that sets out what a business is expected to have considered before personal data goes through a model.

The permission screen is the quiet part. Access granted during a pilot is still granted at scale, and the tool that drafts sales emails has no business reading billing records. There is more on the setup mistakes that cause this in the note on keeping business data safe with AI tools.

What makes an AI system safe once it is running?

Three things, all of them unglamorous: a named human owner for every decision the system makes on its own, a way to switch it off quickly, and a measurement that would catch it going wrong.

NIST's AI Risk Management Framework (AI 100-1, published January 2023) organises this as four functions: govern, map, measure and manage. Measure is the one we most often find missing when we are called in after launch. The system is live, it is producing output, and there is no written definition of a correct output, so nobody can say whether it is working or just running.

The rollback question is quicker to answer and just as useful. If the agent starts doing something wrong on a Friday afternoon, how long until it stops? When the answer is that somebody would have to ask the developer, that is the finding.

It is also the argument for starting where the blast radius is small. A welcome email sequence that goes out badly costs you some unsubscribes. An order confirmation agent that mishandles a delivery address costs you the order, the refund, and a customer who tells people about it. We keep the first two weeks after launch under live monitoring for the same reason, which is how we work.

Do you need a safety audit before you go live?

If the system talks to customers, reaches personal data, or can take an action on its own, yes. The most useful moment is often after it is already live, because by then there are real users and real records behind it, and every week it runs is exposure nobody can see.

The regulation is arriving on a slower timetable than the headlines suggested. The EU AI Act (Regulation (EU) 2024/1689) has been in force since 1 August 2024, and the AI Omnibus that took effect on 27 July 2026 moved the high-risk obligations back: Annex III systems now fall due on 2 December 2027, and AI built into regulated products on 2 August 2028. Whether any of it reaches you depends on what your system decides and for whom, which is the first thing worth working out.

An AI safety audit is the two-week version of this that produces a document. Injection and jailbreak attempts run against the live system. What it does when it does not know an answer. What it must never say, and whether that rule is actually enforced anywhere. Who gets told when it fails, and how fast. Every check is written up as found, not found, or not testable, with the reason.

Ask whoever built it what happens on the day the system is wrong, and whose name is on finding out.

MorningLabs AI builds the agents, automations and internal systems a business runs on, and audits AI systems that are already live.