Can AI Models Like Claude Control Drones? Capabilities, Risks and UK Regulations in 2025

Claude-controlled laser-tracking drone on Reddit: what’s really going on?

A Reddit post claims someone “built a drone that tracks targets with a laser using Claude.” There’s no technical detail in the post itself, but it taps a real question I’m hearing a lot: can large language models (LLMs) like Claude actually control drones?

“This guy build a drone that tracks targets with a laser using claude”

In this piece I’ll unpack what’s feasible today, where the risks sit, and what UK operators need to know in 2025 if you’re even thinking about autonomy and payloads like lasers. Spoiler: LLMs can be part of a control stack, but they’re not flight controllers, and UK law around drones and lasers is strict.

Reddit thread: original post by /u/Alphaxfusion (technical details not disclosed).

Can Claude or any LLM “control” a drone?

Short answer: only at a high level, and only with careful guardrails. LLMs (large language models – AI systems based on the transformer architecture that predict text) are brilliant at reasoning, planning and tool use, but they’re not designed for real-time flight dynamics. Inner control loops need millisecond precision – that’s the realm of flight controllers like PX4 or ArduPilot.

What an LLM can do in a drone stack

• High-level logic: decide goals (“track object A”, “return to base”), interpret rules, and sequence tasks.
• Tool use: call vision models (e.g. object detectors) and send commands over protocols like MAVLink to a flight controller.
• Human-in-the-loop interface: accept natural-language instructions and explain what the system intends to do.

What it shouldn’t do

• Real-time stabilisation or navigation loops.
• Direct actuator control (motors, gimbal) without hard limits and safety interlocks.
• Operate without robust fail-safes, geofencing, and clear abort conditions.

Latency matters. Cloud LLM APIs usually respond in hundreds of milliseconds to seconds, which is far too slow for low-level control. They’re better used as an orchestration layer. If you’ve ever connected an AI assistant to external tools, the pattern is similar – see my guide on connecting ChatGPT to Google Sheets for the general approach of letting a model trigger well-bounded tools.

How “laser tracking” might work, conceptually

Without the builder’s details, we can only describe a typical safe architecture:

• Perception: an onboard camera runs a conventional vision model (e.g. an object detector) to identify and track a target. Multimodal LLMs can interpret images, but continuous video via an API is bandwidth-heavy and slow.
• Planning: the LLM maintains task logic (“if target confidence drops below X, pause and reacquire”), but never sends raw motor commands.
• Control: a flight controller handles stabilisation; a gimbal controller moves a low-power pointer within mechanical and software limits.
• Safety: enforced geofencing, VLOS (visual line of sight), speed/altitude caps, and an immediate override switch. No tracking of people, vehicles or aircraft.

Even then, “tracking with a laser” raises immediate safety and legal red flags in the UK, addressed below.

Key risks: accuracy, misuse and safety with AI-driven drones

Technical risks

• Hallucinations and edge cases: LLMs sometimes produce confident but wrong decisions. Vision can misclassify or drift, especially in poor light or clutter.
• Latency and reliability: network hiccups or API rate limits can stall the planner. Always design for graceful degradation and timeouts.
• Security: exposed tokens or unsecured command channels risk hijack. Use least-privilege credentials, audit logs, and encrypted links.

Physical and ethical risks

• Laser hazards: consumer lasers can cause eye damage. UK law treats misuse very seriously, especially near vehicles and aircraft.
• Privacy: tracking or filming people engages UK GDPR. You need a lawful basis, data minimisation, and clear signage in many contexts.
• Public nuisance and reputational harm: even a “harmless” pointer can alarm bystanders and draw police attention.

UK rules 2025: drones, autonomy and lasers

The UK Civil Aviation Authority (CAA) regulates unmanned aircraft under CAP722 and the UK Drone Code. Where an AI model is making decisions, you’re firmly into “increased automation”, which attracts higher scrutiny.

The basics

• Categories: most hobby flights are in the Open category (A1/A2/A3) with strict limits on weight, proximity to people and flight locations. Add-on autonomy or payloads can push you into the Specific category.
• Registration: if your drone has a camera or weighs 250 g or more, you need an Operator ID. Many pilots also need a Flyer ID.
• VLOS: keep the aircraft in visual line of sight. Beyond visual line of sight (BVLOS) needs specific CAA approval.
• No-fly zones: respect Flight Restriction Zones (FRZ) around aerodromes and other restricted airspace.

Start with the official guidance:

• UK Drone Code (CAA)
• CAA drones and model aircraft hub
• CAP722: Unmanned Aircraft System Operations in UK Airspace

Specific category and autonomy

If you’re adding autonomy or operating near people/urban areas with heavier aircraft, you’ll likely need a Specific category authorisation, a risk assessment (SORA-based), and proof of competence (e.g. GVC). Pre-Defined Risk Assessments (PDRAs) exist for common scenarios but may not cover autonomous tracking or unusual payloads.

Lasers on drones

• Laser misuse: it is a criminal offence to shine lasers at vehicles (including aircraft) under the Laser Misuse (Vehicles) Act 2018. Penalties can be severe.
• Class and power: workplace and public safety rules apply. Handheld Class 3B/4 lasers are hazardous; using them on a drone is likely unacceptable in public spaces.
• Public events: expect to need formal risk assessments, permissions from the landowner and authorities, and robust safety controls. In most hobby contexts, don’t do it.

Also consider insurance and liability. Many commercial operators carry public liability cover; some clients require EC785/2004-compliant aviation insurance. Check your policy if experimenting with autonomy or non-standard payloads – exclusions are common.

Practical guidance for UK builders and researchers

• Keep the LLM out of the control loop. Let PX4/ArduPilot do stabilisation; use the model for explainable, high-level planning only.
• Prefer onboard, deterministic perception for tracking. Use conservative thresholds and mandate human confirmation before any “tracking” action.
• Design hard safety limits: mechanical stops on gimbals, software geofencing, timeouts, and a physical kill switch.
• Test indoors in controlled environments with eye-safe, low-power indicators. Do not track people or vehicles. Avoid public spaces.
• Document your safety case. If pursuing Specific category work, align with CAP722 and relevant PDRAs; consider a GVC and SORA-based assessment.

Why this matters

AI is quickly moving from chat windows to physical systems. The upside is powerful – natural-language control, explainable autonomy, and faster experimentation. The downside is equally real – latency, hallucinations and safety-critical failure modes that consumer AI was never designed to handle.

If a Reddit build inspires you, treat it as a prompt to learn the regulations, design conservatively, and keep humans firmly in the loop. In the UK, that’s not just good engineering – it’s the law.