Adding AI to Your Company: Risks and Opportunities

Most organisations start the AI conversation in the wrong place. They ask which model to use, which vendor is best, and which feature to launch first.

I think that is backwards. The first questions are much less glamorous:

where is the data going?
who is allowed to use the tool?
who approved it?
what happens when it gets something badly wrong?

If those answers are vague, you are not ready. I do not care how impressive the demo was.

That sounds unexciting. It is also the bit that stops expensive mistakes.

Start with the boring controls

If you are adopting an external AI tool, treat it like any other third party first.

That means asking the usual questions around privacy, security, resilience, contractual terms, support, data handling, and exit risk.

I made the same point earlier in Adding AI to your SaaS - Security Risks and Opportunities: most of the normal third-party assessment still applies. The difference is that AI systems add a few nasty failure modes on top.

Prompt injection.

Sensitive data disclosure.

Overconfident nonsense.

Usage patterns that quietly create new privacy problems.

Runaway consumption that turns into a budget problem.

That is before you even get to internal misuse.

The real problem is not the model

In most companies, the biggest AI risk is not some dramatic frontier-model failure.

It is ordinary organisational sloppiness.

People paste sensitive material into tools nobody assessed.

Teams buy copilots on company cards without procurement seeing them.

Staff trust summaries they did not verify.

Developers ship AI-generated code without reading it properly, which is why Is vibe-coding safe? exists in the first place.

That is the pattern I keep seeing.

The model matters. The vendor matters. But governance around usage matters more than most people want to admit.

You do not need to solve everything on day one

You do need some boundaries.

At a minimum, I would want clear decisions on:

what data is never allowed into external AI tools
which teams can approve new AI services
whether prompts, outputs, or uploaded files are retained by the vendor
how staff verify important outputs before acting on them
how access is removed when people change roles or leave
what gets logged, reviewed, and tested

None of that is exotic.

That is basic operational hygiene.

And frankly, if an organisation cannot do those things, it has no business pretending it is ready for broad AI adoption.

Use the public guidance, but do not hide behind it

If you want a good starting point, the OWASP Top 10 for LLM Applications 2025 is a solid reminder of where these systems tend to break.

Use it, but do not turn it into theatre. A checklist will not save you if nobody owns the tooling, nobody knows where the data went, and everyone assumes the output is "probably fine" because the interface looked polished.

That is how bad decisions sneak through: quietly, repeatedly.

The opportunity is real

I am not anti-AI. There are obvious gains here: faster drafting, better search, internal copilots, triage support, analysis assistance, repetitive work that should never have needed a human in the first place.

But those benefits only hold if the organisation stays in control of how the tools are used.

That is what I mean by governance.

Not a policy document nobody reads. Actual working rules:

who can buy AI tools
who can use them
what data is allowed in and out
what systems can be interacted with
how are AI connections, actions, decisions recorded
when outputs must be checked by a human
who owns the decision if something goes wrong

That is the work.

If you skip it, AI adoption does not become strategic. It becomes a series of local decisions made by whichever enthusiastic team has budget, access, and the confidence to move first.