There is a moment in building any AI system when you get something that looks like it is working. The output looks plausible. The numbers are in range. Nothing obviously wrong. That moment is when most small producers stop. They call it done, they use it, and six months later they discover that plausible and correct are not the same thing. The system was confidently wrong for months, in a direction that was hard to detect until the consequences showed up in a cash-flow spreadsheet.
I have been through this. The fix is not more sophisticated AI. It is building the right layers in the right order before you trust the output on anything finance-adjacent.
Why layering is the architecture decision for small producers
The ONS 2026 survey of AI in UK businesses found that difficulty identifying suitable use cases was the most commonly reported barrier to AI adoption. For finance-adjacent decisions, that identification problem has a sharp edge: a wrong recommendation on restocking or account prioritisation has immediate, measurable consequences that you will feel before you have a chance to notice the system was wrong.
Layering is the architecture that makes identification tractable. Each layer is independently verifiable. You can audit the data layer without understanding the model. You can test the compliance layer without running the full system. When something goes wrong, the layers tell you where to look.
There are four of them. Each one does a distinct job.
Layer one: data
Every AI system is only as good as its inputs. For a small drinks business, inputs are typically a mess. Sales data lives in Shopify. Account notes live in a CRM that three people use inconsistently. Reorder history lives in email threads. Production records live in a shared spreadsheet that gets updated when someone remembers.
The data layer is not a technology problem. It is a discipline problem. It means deciding, in advance, what structured format your operational data needs to be in, and then maintaining that structure consistently. Which fields are mandatory. How accounts are named and categorised. What counts as a reorder versus a sample versus a return.
This work takes longer than any of the other layers. It is also the work that makes everything else possible. A model running on clean, consistent data is genuinely useful. A model running on the data layer described in the previous paragraph is a generator of confident-sounding plausible answers.
Layer two: insight
The insight layer makes your data visible and interpretable without yet making recommendations. It is the difference between a dashboard that shows you what happened and a system that tells you what to do next.
This distinction matters. An insight layer is low-risk to build and use because it is not taking actions, it is surfacing patterns. You can validate an insight layer with your own domain knowledge: does this pattern match what you already knew? Does it surface anything you did not know but can verify?
At Asterley Bros, our first operational AI layer was pure insight: which accounts had not reordered in 90 days, which SKUs were moving slower than last year, which postcodes showed patterns the seasonal calendar did not explain. We ran that for eight weeks before asking the system to start making recommendations. The eight weeks were for building our own trust in the data.
Layer three: compliance
The compliance layer is a set of explicit rules that check AI outputs against your operational constraints before the output reaches you as a recommendation.
For a restocking system, compliance rules might include: does this recommendation fall within the cash-flow envelope for the month? Does it conflict with any purchase commitment already in the pipeline? Is it consistent with the seasonal demand pattern? If any of those checks fail, the output gets flagged rather than passed through.
The compliance layer is most important for finance-adjacent decisions, and this is where most small producers underinvest. They build a system, trust its outputs because they look reasonable, and skip the explicit rule layer. The system then makes a confident recommendation that fails on a constraint the founder would have caught immediately if they had been checking manually. The ONS research on AI in UK businesses shows that data accuracy and compliance are among the top concerns for firms using AI in financial workflows.
Layer four: safety
The safety layer monitors the system itself rather than individual outputs. It watches for drift: has the model started behaving differently from how it behaved three months ago? It watches for anomalies: is this output statistically unusual in a way that suggests something has gone wrong upstream? It watches for data feed failures: is the system running on stale inputs without flagging it?
In a small team, the safety layer is often the thing that gets built last or not at all, because it only shows its value when something goes wrong. That is a mistake. The safety layer is cheapest to build before you deploy and most expensive to retrofit after a failure. A practical safety layer does not need to be complex. A set of threshold alerts, a weekly review of output distributions, and a log that someone actually reads. The discipline matters more than the sophistication.
| Application type | Data layer | Insight layer | Compliance layer | Safety layer | Worst-case bad output |
|---|---|---|---|---|---|
| Tasting notes generator | Recommended | Optional | Not needed | Not needed | One draft you rewrite |
| Social caption tool | Recommended | Not needed | Not needed | Not needed | One post you delete |
| Account health check | Required | Required | Recommended | Optional | Missed reorder signal |
| Demand forecasting | Required | Required | Required | Required | Wrong stock, cash cycle affected |
| Account prioritisation | Required | Required | Required | Required | Wasted sales visit, missed quarter |
| Pricing recommendation | Required | Required | Required | Required | Margin erosion, bad trade decision |
Sequencing the build
The order matters. Data first, always. Insight second. Compliance third. Safety fourth. Skipping the sequence and jumping straight to recommendations produces systems that look impressive in demos and fail silently in production.
Without the layers, you have a tool. With them, you have a system you can actually trust, maintain, and improve over time.
How long does it take to build all four layers for a small drinks business?
In our experience building for Asterley Bros: the data layer takes two to three months if you are starting from an unstructured state. The insight layer takes four to six weeks once the data layer is stable. Compliance rules can be built in a week or two once you have articulated what the operational constraints actually are. The safety layer takes a day or two to instrument and a few weeks to calibrate. Call it six to eight months for a complete first implementation, with the data layer the longest and most important phase by far.
What is the most common mistake small producers make when building AI systems?
Skipping the data layer because the data looks good enough. It rarely is. The gap between data that looks reasonable and data that is actually consistent enough to build on is usually larger than it appears until you start building. The second most common mistake is skipping the compliance layer for finance-adjacent decisions on the grounds that the output looks right. Looking right and being right are not the same thing, especially when the feedback loop is months long.
Can a small team run all four layers without a dedicated data engineer?
Yes, but the architecture has to be built for maintenance by a non-specialist. That means favouring structured data stores that are legible to non-engineers over complex pipelines that only one person understands. It means documenting the compliance rules in plain language, not just in code. And it means building the safety layer to alert loudly on anomalies rather than expecting someone to audit logs manually. The goal is a system that a team of six can run and maintain without needing to hire a data team.
---
Robert Berry is co-founder of Asterley Bros, a London-based premium aperitivo company, and Absolution Labs, an AI automation consultancy for drinks businesses. He makes vermouth by day and builds AI systems in the margins.
More on how we build and think about AI architecture for small producers at absolutionlabs.com.