The Red Flag Problem: why “wait and see” is the most expensive AI strategy

In 1865 Parliament passed the Locomotives Act. Any self-propelled vehicle on a public road was limited to 4 mph in the country and 2 mph in town, needed a crew of three, and one of the three had to walk sixty yards ahead carrying a red flag.

It's easy to laugh at now. At the time it made sense. The law was written for steam traction engines: heavy, loud, terrifying for horses and brutal on road surfaces. Someone saw a real risk and wrote a sensible-sounding rule for it.

The trouble came later. When the motor car arrived, it was squeezed into the same rules. A machine built to go fast was legally obliged to follow a man on foot. The rule was softened in 1878, but the walker only disappeared in 1896, when the speed limit roughly tripled overnight. Motorists celebrated by driving from London to Brighton, and a red flag was torn up at the start. The run still happens every November.

Meanwhile Karl Benz had patented his Motorwagen in Germany in 1886, and French firms were already selling cars. Historians still argue about how much of Britain's slow start was the Act's fault. Nobody argues that it helped.

That law is worth remembering, because most companies today aren't against AI. They've simply put a man with a red flag in front of it.

What the red flag looks like in 2026

It almost never looks like a ban. It looks like reasonable caution.

"Let's wait until the tools mature." Tools mature by being used. The teams using them now are learning which tasks are actually worth automating, and that knowledge doesn't come in the box.

"Let's see how it works out for others first." You will see. By then they'll have the process know-how, the cleaned-up data and the staff who trust the system. That's the part you can't buy off the shelf later.

Every AI output checked by a person, line by line, for ever. Human review is exactly right at the start. Make it permanent and you've hired someone to walk in front of the car.

The pilot that never ends. Six months of "exploring", nothing in production and no number anyone is tracking.

Old rules for a new tool. The sign-off process designed for a six-figure ERP upgrade, applied to a two-week experiment.

Each of these is defensible on its own. Together they set your business to walking pace while the people around you are already on the train.

Why waiting costs more than it looks

Waiting feels free because the bill never arrives as an invoice. It arrives as:

• Hours. The same documents re-keyed, the same customer questions answered by hand, every single week.
• People. Good staff don't stay long in jobs that are mostly copy and paste.
• Learning. Your first AI project is rarely your most valuable one. It's the one that teaches you how to run the second. Delay the first and you delay all of them.
• Expectations. Early movers reset what customers consider normal: faster replies, quicker quotes, fewer "we'll get back to you". Eventually you match their service level on their timetable, not yours.

Speed without a seatbelt isn't the answer either

I'm not arguing for ripping out the flag and putting your foot down. The 1865 Act existed because those machines really were dangerous to other road users. AI has real risks too: personal data under UK GDPR, wrong answers delivered with total confidence, and systems nobody owns once the consultant has gone home.

The answer to a real risk is a proper safety system, not a walker. In practice that means five things.

1. Pick one process, not a strategy deck. Something manual, repetitive and measurable: matching invoices, triaging support emails, pulling data out of PDFs.
2. Agree the number before you start. Hours per week, response time, error rate. If you can't measure it, it's the wrong first project.
3. Check the plumbing first. Most AI projects stall on integration, not on the model. Find out whether your CRM, your Rails app or your SharePoint can actually talk to it before you commit.
4. Keep a person in the loop, and plan how they step back. Review everything in week one, a sample in month two, only exceptions after that.
5. Name the owner before go-live. Updates, quality, incidents. Your own team or a support contract, but a name, agreed upfront.

Fixed scope, a few weeks, a clear yes or no. That's how you find out whether AI works for your business without betting the business on it.

We took our own flag down first

It would be a bit rich to write all this while walking behind a flag of our own. So we changed how we work: everyone at Rubyness is now a forward deployed engineer.

Not a developer waiting for a perfect spec. Not a consultant who leaves behind a slide deck and an invoice. An engineer who works inside your process, finds where the hours leak out and ships the fix where the work actually happens. The five steps above aren't theory for us. They're the job description.

A quick test: is there a red flag in your company?

• Has anyone suggested an AI use case in the last six months that's still "being looked at"?
• Do you have a rule for AI that you wouldn't apply to any other tool?
• Could you name the one process that would free up the most hours if it ran itself?
• If a competitor started answering customers twice as fast next month, would you know how to respond?

If your answers were yes, yes, no and no, the man with the flag is already walking ahead of you.

Get on the train

The people who scrapped the red flag weren't reckless. They just noticed that the rule had outlived the problem it was written for.

If there's a process that eats your team's week, tell us about it. One of our forward deployed engineers will come back with a suggested first step, a fixed scope and an honest view on whether AI is the right tool for the job. Sometimes it isn't, and we'll tell you that too.