Every automation will, at some point, do something nobody intended. A rule misfires, an integration changes, a model misreads an instruction. In a well-run small business, that should be a manageable incident: noticed quickly, stopped cleanly, understood afterwards. In a poorly prepared one, it becomes a weekend of guesswork. The difference is rarely the technology. It is whether anyone planned for the failure before it happened.

A cautionary example

In April 2026, Euronews reported on PocketOS, a software provider for car rental businesses, whose AI coding agent deleted the company's production database while working on a routine task, apparently trying to resolve a credential mismatch. According to the report, the backups were deleted as well, and customers lost access to bookings and records during an outage of more than 30 hours before the data was recovered. The founder described the deletion as taking nine seconds.

The specifics involve a developer tool rather than a typical SME workflow, but the pattern is general. An automated system had permissions broad enough to do irreversible damage, backups were within its reach, and no step required a human to confirm a destructive action.

Most firms are not yet prepared

The Swiss picture suggests this is worth attention. The latest swissVR Monitor, produced with Deloitte and the Lucerne University of Applied Sciences and Arts and based on a survey of 281 board members, found that 55 per cent of companies have no contingency plan, or an untested one, for restoring core IT processes. Among small companies, only 32 per cent had tested plans. The same survey found that 74 per cent of companies have no explicit strategy for AI-based attacks.

Logging: what to record

Security guidance on AI systems consistently treats logging as the safety net for risks that cannot be fully prevented. OWASP recommends logging and monitoring the actions of AI integrations and the downstream systems they touch, along with rate limits so that problems are caught before they scale. The UK National Cyber Security Centre goes further and suggests logging inputs, outputs and every tool or API call, and watching for repeated failed calls, which can indicate someone probing the system.

For an SME automation, a useful log entry answers six questions:

  • When did it run, and which version of the workflow was it?
  • What triggered it: which email, form or record?
  • What did the AI produce: the draft, classification or extracted fields?
  • What action was taken, in which system, on which record?
  • Who approved it, if a human checkpoint was involved?
  • Did anything fail, and what was the error?

Keep logs somewhere the automation itself cannot edit or delete, set a retention period that suits your data protection obligations, and avoid copying more personal data into logs than you need to reconstruct events.

A one-page incident plan

You do not need a thick binder. You need answers written down before you need them:

  1. An owner for each automation. One named person who can be reached and who knows what it does.
  2. A stop switch. A documented way to pause the workflow in under five minutes, such as disabling the trigger, revoking its credentials or switching it to draft-only mode. Test it once.
  3. Backups out of reach. Backups that the automation's credentials cannot modify or delete, and a restore you have actually tried.
  4. A triage checklist. What did it do, to which records, since when? Did personal data go anywhere it should not have? Is it still happening?
  5. A notification decision. Who decides whether customers, partners or the authorities need to be told, and by when?
  6. A short review. Once things are stable: what happened, why the safeguards did not catch it, and what changes.

How Swiss notification rules fit in

If an automation exposes, alters or loses personal data, the Data Protection Act may apply. Under Article 24, a controller must notify the FDPIC as quickly as possible of a data security breach that is likely to result in a high risk to the people affected, covering at minimum the nature of the breach, its consequences and the measures taken or planned. Affected individuals must be informed where that is needed for their protection. A processor, such as an automation provider acting on your behalf, must tell you about any breach. The FDPIC publishes guidelines and an online reporting form for this process.

Two practical points follow. Your contract with any automation provider should say how quickly they will tell you about an incident. And your triage checklist should include the question "is this likely to be high risk for the people concerned?", so that the decision is made deliberately rather than by default.

Build it in from the first workflow

The cheapest moment to add logging, a stop switch and a restore test is when an automation is first built. Retrofitting them after an incident is slower and more stressful. If you are commissioning your first AI workflow, make these part of the definition of "done", alongside the time it saves.

Want a second pair of eyes on how your automations would fail? The free AI Readiness Audit covers human checkpoints, logging and recovery as part of scoping.

Sources

  • Euronews, "An AI agent deleted a company's entire database in 9 seconds — then wrote an apology", 28 April 2026. link
  • Deloitte Switzerland, "AI-based cyber-attacks accentuate risks for SMEs – boards of directors are lagging behind the latest developments", 16 September 2026. link
  • OWASP Gen AI Security Project, "LLM06:2025 Excessive Agency", 2025. link
  • UK National Cyber Security Centre, "Prompt injection is not SQL injection (it may be worse)", 8 December 2025. link
  • Federal Data Protection and Information Commissioner (FDPIC), "Guidelines on data breaches", 7 February 2025. link
  • Justement (FADP text), "Art. 24 FADP", in force since 1 September 2023 (consulted 7 November 2026). link