Adding AI to your product without the risk

Where AI pays back for a small business

AI earns its cost on work that is frequent, slow and easy to check. Think of drafting replies to routine enquiries, summarising long documents, sorting incoming requests, pulling details out of forms and invoices, or writing a first draft that a person then edits. Each one happens often, eats time, and a person can tell quickly whether the output is right.

It struggles where those three things are missing. A task that happens twice a year will not repay the effort of setting it up. A task where a wrong answer is expensive and hard to spot is risky to hand over. And a task that a simple rule could handle does not need AI at all: a spreadsheet formula or a form with good defaults is cheaper, faster and never makes things up.

So the question I ask first is not "where can we use AI?" It is "which task costs us the most time, and how quickly would we notice if a machine got it wrong?" Start with the task that scores well on both.

Before building anything, write down how long that task takes today and what it costs. That number is how you will know whether the AI paid back, rather than guessing afterwards. If you want help finding the opportunity with the best return, that is the first week of an Innovation Build.

Agents or simple features?

The difference is simple. A feature answers. An agent acts.

A feature drafts the email, summarises the contract or suggests a category. A person reads it and decides what happens next. An agent goes further: it calls tools, sends the email, updates the record or starts a payment, often several steps in a row without anyone checking in between.

Simple features are often the better choice. They are cheaper to build, easier to test, and the risk stays contained because a person is still the one who acts. Many of the gains people expect from agents come from a well-placed feature.

Once software can take actions, the risk changes shape. Mistakes happen at machine speed and can repeat before anyone notices. An agent can reach other systems through the tools you give it. And it can be steered by what it reads: instructions hidden in an email, a document or a web page can push it to do something you never intended.

None of that moves responsibility away from you. The ICO's research on agentic AI makes the point plainly: AI agency does not remove the organisation's responsibility for the personal data its systems process.

Source: ICO tech futures: agentic AI, data protection and privacy risks (opens in a new tab), correct as of 5 October 2026.

My rule of thumb: start with a feature, watch how it performs, and let a step become automatic only once you have seen it get that step right many times.

Permissions and least privilege

Least privilege means each agent gets only the tools and data its task needs, and nothing it might find useful later. It is the single most effective guardrail, because an agent cannot misuse access it was never given.

The ICO says the same about agentic systems: organisations should not give them access to information just because it might be useful in the future, and need a justifiable reason for every piece of information an agent uses.

Source: ICO tech futures: agentic AI, data protection and privacy risks (opens in a new tab), correct as of 5 October 2026.

In practice, that looks like this:

• One job, one set of keys. Each agent gets its own credentials, scoped to its task, so you can see and switch off exactly what it can do.
• Read and write kept apart. An agent that only needs to look things up should not be able to change them.
• Test and live kept apart. Agents are developed and tested against test data and test accounts, never against your real customers.
• Limits on anything that costs money. Spending caps, rate limits and short-lived access, so a mistake cannot run away with your budget.
• A short list of allowed actions. Name what the agent may do. Everything else is refused by default.

FounderCrush, the agentic AI co-founder I built, works this way. It helps entrepreneurs with company formation, compliance, banking, insurance and operational setup, and each agent is limited to the permissions its part of that job needs. You can read how FounderCrush scopes its agents in the case study.

Consent and personal data

UK data protection law applies the moment an AI feature handles personal data. You need a lawful basis for the processing, and consent is only one of them. The ICO's guidance lists the lawful bases and is clear that no single basis is better than the others, so choose the one that fits what the feature does.

Source: ICO, a guide to lawful basis (opens in a new tab), correct as of 5 October 2026.

Whatever the basis, the data minimisation principle still applies: only process the personal data you need for the purpose. The ICO's guidance on AI and data protection explains how that works for AI systems. It is under review following the Data (Use and Access) Act 2025, so check the current version before relying on any detail.

Source: ICO, how should we assess security and data minimisation in AI? (opens in a new tab), correct as of 5 October 2026.

If your product makes significant decisions about people with no meaningful human involvement, the rules changed on 5 February 2026. New articles in UK GDPR now allow those decisions in wider circumstances, but only with safeguards: people must be told about the decision and be able to make representations, ask for a human to step in and contest it. Decisions that rely on special category data, such as health information, are more tightly restricted. The ICO has consulted on updated guidance on automated decision-making.

Source: Data (Use and Access) Act 2025, section 80, in force from 5 February 2026 (opens in a new tab), correct as of 5 October 2026.

Beyond the legal minimum, I would still ask before an agent acts on someone's behalf. FounderCrush uses explicit consent flows: the founder agrees to what an agent will do before it does it. People trust a product more when it asks first.

Finally, keep personal data out of places it does not need to go. Strip names and contact details from text before it reaches a model if the task does not need them. Check whether your AI provider uses your data to train its models and where it stores it. And remember that prompts and logs are data too.

Audit trails

An audit trail records what the agent saw, what it decided and what it did, along with who approved what and when. When something goes wrong, it is the difference between "we think the agent did something odd" and knowing exactly which step failed and why.

A useful trail captures:

• the request the agent started from
• the information it looked up or was given
• each tool it called, with what inputs, and what came back
• the final action, and any human approval along the way

Someone has to read it. Give a named person the job, look at the trail regularly while a feature is new, and set alerts for anything unusual, such as a spike in actions or an attempt to use a tool the agent is not allowed. Logs nobody looks at are not a guardrail.

Use the trail to improve the product, not only to defend it. The tasks an agent failed, the outputs people corrected and the approvals that were rejected tell you exactly where to tighten a permission, fix an instruction or add a check. A good trail also helps when someone asks what you did with their data.

Apply the same care to the trail itself. It can hold personal data, so keep only what you need, restrict who can read it, and delete it on a schedule. FounderCrush keeps an audit trail of what its agents do for exactly these reasons.

Human approval for money and sensitive data

Some actions should always wait for a person. My list for a small business:

• anything that moves money, signs up to a cost or changes a payment
• sharing personal or sensitive data with anyone outside the business
• submitting something formal on someone's behalf
• changes that are hard to undo
• messages that go out in your name, at least until you have watched the agent write them well

Approval only works if it is quick and clear. Show the person exactly what will happen, in plain words, and exactly what data will be shared. Make approving and rejecting one click each. Do not ask for approval on trivial steps: if people are asked to confirm everything, they stop reading and confirm anything, and the guardrail quietly disappears.

In FounderCrush, agents cannot reach sensitive financial or personal data without the founder's approval. An agent can do the groundwork on banking or insurance, but the decisions that touch money or personal details stay with a person.

If you are planning an AI feature and want these guardrails designed in from the first week, rather than added after something goes wrong, that is what an Innovation Build is for.