Around 73% of organisations now use or are piloting AI in core functions. That figure marks a transition most businesses have not consciously registered: AI stopped being a feature somebody was evaluating and became infrastructure everybody depends on. Infrastructure has different rules.
The question changed and nobody sent a memo
Two years ago the conversation in most boardrooms was “should we be using this?” That question has effectively resolved itself, usually without a decision being made. Teams adopted tools individually, the tools became load-bearing, and now the organisation depends on systems it never formally evaluated.
The question now is not whether to use AI. It is whether you can describe what it is doing, who authorised it, what data it touched, and what happens when it is wrong. Most organisations cannot answer any of those with confidence.
The pattern we keep meeting
A team quietly adopts a tool. It works. It becomes load-bearing. Eighteen months later nobody can say which customer data has passed through it, under whose contract, or what the retention terms were. Nobody made a bad decision. Nobody made a decision at all.
Three questions worth answering before the next tool
1. What data leaves the building?
Not in principle — in fact. Which systems, which fields, which vendors, under what terms. If you handle personal data this is not merely good practice; it is the substance of what your privacy policy already claims about third-party processors. A policy describing controls you do not have is worse than no policy.
2. Who is accountable for the output?
“The model produced it” is not an answer that survives contact with a client, a regulator or a court. Someone owns the output. If that is unassigned, it defaults to whoever is standing closest when it fails, which is a poor way to run anything.
3. What does the failure look like?
Every system fails. The useful question is whether yours fails loudly or quietly. A model that returns an obvious error gets caught. A model that returns a plausible, subtly wrong answer — consistently, at scale, inside a process nobody reviews — is a different category of problem.
What good looks like, roughly
- An inventory. An unglamorous list of what is in use, by whom, touching what. Most organisations do not have this and are surprised by their own list.
- A data boundary. An explicit statement of what may and may not be sent to a third-party system, written for people who are not lawyers.
- Named ownership. Per system, not per department.
- A review point. Something that fails visibly before it fails expensively.
- A retirement path. The ability to stop using a tool without stopping the business.
The consultant's honest caveat
None of this is exotic. It is ordinary operational governance applied to a category of tool that arrived faster than most governance processes could track. The reason it gets skipped is not that it is difficult. It is that it is boring, it competes with visible work, and nothing bad has happened yet.
That last clause is doing an enormous amount of load-bearing work in a lot of organisations right now.
Key takeaways
- Roughly 73% of organisations already use or pilot AI in core functions — the adoption question is settled
- Most teams cannot say what data left, under whose contract, or who owns the output
- Quiet, plausible failures are the real risk, not obvious ones
- Start with an inventory and a written data boundary — both are cheap
- This is ordinary governance applied late, not a novel discipline
Want this handled properly?
Tell us what you're working with and we'll scope it with you — no obligation.