Governance has two failure modes, and most firms pick one
When a scaling company finally takes AI seriously, it usually lurches to one of two extremes. The first is the cowboy: no policy, no register, staff quietly pasting customer records into whatever chatbot they fancy, an agent wired straight into the billing system because it was quicker that way. The second is the committee: a forty-page policy borrowed from a bank, a review board that meets monthly, and a sign-off process so heavy that every useful AI project dies in a queue.
Both are failures. The cowboy ships risk you cannot see. The committee ships nothing at all, then congratulates itself on being compliant. For a mid-market business without a dedicated compliance department, neither is affordable. What you need is governance that is real enough to catch the things that genuinely hurt you, and light enough that a team of ten can run it without hiring a Chief AI Ethics Officer.
This guide gives you a right-sized framework: seven moving parts, most of which fit on a single page. It is written for the founder, CTO or operator who has to make this work on a Tuesday, not for a regulator. One caveat before we start. This is general information, not legal advice. Where a date, threshold or article number matters to a decision you are about to make, confirm the current position with a qualified adviser, because the rules are moving faster than most guides can keep up.
What actually applies to you in 2026
Start with the reassuring part. There is still no UK AI Act. As of mid-2026 no comprehensive AI bill sits before Parliament. The government has held to its pro-innovation, principles-based approach: five cross-sectoral principles (safety and robustness, appropriate transparency and explainability, fairness, accountability and governance, and contestability and redress) that existing regulators such as the ICO, FCA, Ofcom and CMA apply within their own patches. DSIT published its Blueprint for AI regulation in October 2025, and a Regulating for Growth bill has been trailed to create regulatory sandboxes under an AI Growth Lab. None of this bans much.
But do not mistake “no AI Act” for “no rules”. UK GDPR and the Data Protection Act 2018 already govern how you use personal data in AI, including provisions on automated decisions that significantly affect people. The Equality Act 2010, consumer law and your sector regulator all still apply. AI does not get a carve-out.
The bigger stick for most UK scale-ups points across the Channel. The EU AI Act entered into force on 1 August 2024, and its reach is extraterritorial. Under Article 2 it applies to you if you place an AI system on the EU market, or if the output of your system is used in the EU, regardless of where you are based. Brexit is not an exemption. If you sell to EU customers, or your product’s AI features touch EU users, you are in scope.
The Act sorts AI into risk tiers. A short list of practices is simply banned under Article 5, in force since 2 February 2025, covering things like social scoring and certain manipulative or biometric-categorisation uses. High-risk systems, listed in Annex III (recruitment, credit, education, essential services and so on), carry the heaviest obligations. Most business software sits in the limited or minimal tiers, where the main duty is transparency.
Two dates matter right now. First, the transparency obligations under Article 50 still apply from 2 August 2026: if a user is interacting with an AI system, or content is AI-generated, you generally have to disclose it. Second, and this is the big 2026 change, the heavy high-risk obligations have been pushed back. Under the Digital Omnibus on AI simplification package (agreed politically in May 2026, endorsed by the European Parliament on 16 June and given final Council approval on 29 June 2026, with publication in the Official Journal imminent), the Annex III high-risk deadline moved from 2 August 2026 to 2 December 2027, and product-embedded high-risk systems under Annex I moved to 2 August 2028. Because this only takes full legal effect on publication, treat those exact dates as the current best position and confirm before you build a roadmap around them.
Why care if you think you are low-risk? Penalties. Under Article 99, using a banned practice can cost up to 35 million euros or 7% of global annual turnover, whichever is higher. Other breaches reach 15 million euros or 3%, and giving regulators incorrect information can cost 7.5 million euros or 1%. Those are the ceilings, not the going rate, but they set the tone. The rational response is not panic. It is to know exactly where you stand, which is what the rest of this framework delivers.
A one-page AI use policy
Your policy should fit on one page. If it runs longer, nobody reads it, and an unread policy governs nothing. The job of this page is not to be exhaustive. It is to answer the four questions a normal employee actually has.
Which tools are allowed? Name the approved systems and say that anything else needs a quick check first. What data must never go in? Be blunt: no customer personal data, no credentials, no unreleased financials in a public model. When do you have to disclose AI? Spell out that AI-generated content and AI conversations with customers get labelled, which also happens to be the Article 50 duty landing in August 2026. Who do I ask? Give a named person and a channel.
Write it in plain English, publish it where people work, and put a review date on it. A one-page policy that everyone has read beats a beautiful forty-page one that lives in a shared drive nobody opens.
A register of where AI touches the business
You cannot govern what you cannot see. The single highest-leverage move for a company with no compliance function is to build a register: a simple table listing every place AI touches the business. One row per use. Columns for what it does, what data and decisions it touches, a risk tier (banned, high, limited or minimal, mapped loosely to the EU tiers above), the vendor behind it, whether a human reviews its output, and the date you last looked at it.
Most rows will be dull and low-risk: transcription, drafting, code assistance. That is the point. The register does not exist to slow those down. It exists to surface the two or three uses that quietly touch hiring, credit, pricing or irreversible customer actions, so you can put your limited attention there.
Two things make a register honest. First, you have to actually know your data, which is harder than it sounds in an older business. When the team helped retire a 779-column legacy system at CoolKit, the first real task was not the AI at all: it was mapping what each of those columns genuinely held before anything could be trusted to read from or write to them. Governance starts with that kind of inventory. Second, keep the register live. Review it quarterly, and require a new row before any new AI use goes into production. A register that is twelve months stale is a museum piece, not a control.
One named owner per system
Every high or limited-risk row in your register needs a single named human owner. Not “the AI team”, not “engineering”, a person. A system that belongs to everyone belongs to nobody until it goes wrong, at which point it belongs to everybody at once, usually in a crisis.
The owner is accountable for three things: that the use still matches what the register says, that its human gates and logging still work, and that they are the first call when it misbehaves. This is the heart of what we call agent-readiness. An organisation is ready to deploy autonomous systems not when the model is clever, but when every consequential thing the model can do has a person answerable for it. Clear ownership is cheap to set up and it is the control that makes all the others enforceable.
A human in front of anything you cannot undo
Here is the discipline that matters most, and it is one we apply to our own systems. Do not rely on telling a model “never do X”. A prompt instruction is a request, not a safeguard. If an agent must never issue a refund above a threshold, never delete a record, never send an external email unreviewed, then the reliable control is to not put that capability on its keyring in the first place. Remove the key, or route the action through a human approval step. An instruction you can bypass is not a guardrail. A capability the system does not have is.
So draw a line around anything irreversible or high-stakes, money leaving the business, communications sent in your name, data deleted, decisions that affect a person’s job or credit, and require a human to approve before it happens. Everything reversible and low-stakes can run freely, which is what keeps the framework light.
Rogue’s own prospecting engine works exactly this way: an adversarial verifier, a separate judge model, reviews every message against the rules before anything is auto-sent, and anything it is unsure about stops for a person. When mdlondon’s live AI assistant talks to a customer, it makes clear it is an assistant, which is both good manners and the transparency the EU rules now expect. The pattern scales down to a ten-person team: decide what the system is allowed to do on its own, and gate the rest.
Logs you can trust, and evaluation before you grant it
Two controls travel together here. The first is the audit trail. For anything in your high or limited tier, log the inputs, the model’s output, and the human decision, with who and when. This is not bureaucracy for its own sake. When a customer disputes an outcome, or a regulator asks how a decision was made, or you simply need to debug why the agent did something odd, the log is the only thing that lets you answer honestly instead of guessing. Keep it tamper-evident and retained long enough to matter.
The second is evaluation before trust. Do not promote an AI feature to “runs on its own” because it looked good in a demo. Build a golden set: a fixed collection of real inputs with known-correct answers, and measure the system against it before you loosen the reins, then re-run it whenever you change the model or the prompt. The rule we hold to is that uncertainty counts as failure. If the system is not confident, that is a fail, not a maybe, and the action falls back to a human. Speed and rigour are not opposites here. The team built the UpGrades product, which runs several AI roles, in 13 days, and it still shipped behind evaluation gates rather than hope. Fast and governed is a choice you can make.
Vendor and data due diligence
Most of your AI risk arrives through someone else’s model, so vet the vendors. Before you adopt a tool, get clear answers to a small set of questions. Where is our data processed, and does it leave the UK or EU? Will our inputs be used to train their models, and can we switch that off? What are their sub-processors and their security posture? What happens to our data when we leave? Do they give you what you need to meet your own disclosure and record-keeping duties?
On the data side, apply the discipline of minimisation: send the model the least it needs, strip personal data you do not require, and keep provenance for anything that feeds a consequential decision. If you would not be comfortable explaining to a customer that their data passed through a given system, that is your answer. A short, standard vendor questionnaire, reused for every tool, turns this from a research project into a ten-minute checklist.
An incident path, and a 90-day way to start
Finally, decide before you need it what happens when an AI system does something wrong, because it will. Write a short runbook: who gets called, how you pause or disable the system (the kill switch the owner controls), how you assess harm, whether you owe anyone a disclosure or a regulator a notification, and how you review the logs to find the cause. A one-page incident path that exists beats a perfect plan you improvise at 2am.
Here is a right-sized way to stand all of this up in 90 days. In weeks one and two, write the one-page policy and build the first draft of the register. In weeks three to six, assign a named owner to every high and limited-risk row, and put human approval gates in front of the handful of irreversible actions you found. In weeks seven to ten, turn on logging for those systems and build your first golden set so you can measure before you trust. In weeks eleven and twelve, run the vendor questionnaire across your main tools, write the incident runbook, and schedule the first quarterly review. That is not a compliance department. It is a founder, an afternoon a week, and a framework that fits the business you actually have.