Back to blog
AI incident reporting EU AI Act compliance SME AI governance AI transparency

AI Incidents: The Reporting Rules SMEs Can't Ignore

New EU AI Act duties and disclosure norms mean SMEs need incident response plans now. Learn what to track, when to report, and how to stay compliant.

Published on September 17, 2026 by Agenticalia

A faulty customer-service bot misquotes a price. A supplier-risk agent flags a solvent vendor as insolvent. A CV-screening tool rejects every female applicant. These are not hypothetical edge cases—they are the kind of “serious incidents” that new EU rules expect companies to report, and soon.

Most SME leaders assume AI incident disclosure applies only to big tech or high-risk systems. That assumption is about to get expensive. Even systems classified as limited-risk can trigger transparency duties, and customers increasingly expect you to say when AI went wrong. The Reuters news hook this week asked bluntly whether AI companies have to disclose dangerous incidents. The answer is shifting from “maybe” to “yes, under defined conditions.”

What the EU AI Act Actually Requires

The AI Act entered into force in 2024, with obligations phasing in through 2027. For SMEs, the most relevant duties are not the ones for “high-risk” systems like medical devices or critical infrastructure. They are the horizontal transparency rules and the incident-reporting expectations that apply across many AI deployments.

Under the Act, providers of high-risk systems must report serious incidents to national market surveillance authorities. A serious incident includes death, serious harm to health or property, or significant disruption to fundamental rights. But the Act also creates a broader expectation: deployers of AI systems that interact with humans must inform people they are talking to a machine. That includes chatbots, voice agents, and automated email responders.

If your AI system misleads customers, discriminates, or causes measurable harm, you may face obligations even if the system is not classified as high-risk. The key is not the label on the system. The key is what happened and who was affected.

Why Disclosure Norms Are Expanding Beyond the Law

Legal requirements set a floor. Customer expectations are raising the ceiling. When an AI agent makes a mistake that costs a client money or time, silence is no longer a safe default. Buyers of B2B services increasingly ask vendors about AI incident history during procurement. Insurers ask about AI governance before underwriting cyber or professional liability policies.

The Reuters piece highlighted that regulators and courts are wrestling with whether AI companies must reveal dangerous incidents proactively. Some argue voluntary disclosure builds trust; others fear it invites litigation. For SMEs, the practical middle path is clear: you do not need to publish every glitch, but you do need a documented process for identifying, assessing, and reporting incidents that matter.

A simple rule: if an incident would change a reasonable customer’s decision to keep using your service, it probably warrants disclosure.

What Counts as a Reportable AI Incident

Defining “incident” too narrowly is the most common SME mistake. Most owners think only of data breaches or system outages. AI incidents are broader and often quieter.

Consider these categories:

Category Example Likely reporting trigger
Harmful output Chatbot gives dangerous medical or legal advice Serious harm to a person
Discriminatory outcome Screening tool systematically rejects applicants over 50 Fundamental rights impact
Misrepresentation AI agent claims a product feature that does not exist Consumer protection law
Security failure Prompt injection causes agent to leak internal data Data protection authority
Operational drift Demand-forecasting model degrades silently, causing stockouts Contractual breach with clients
Financial error Invoice-processing agent pays a duplicate invoice Material financial loss

Not every row requires external reporting. But every row should be logged internally. That log is your evidence of good-faith governance if a regulator or customer later asks questions.

Building an SME-Grade Incident Response Process

You do not need a dedicated AI compliance team. You need a simple, repeatable process that fits your existing operations.

Start with ownership. Assign one person—often the operations lead or a technical co-founder—to own AI incident response. That person decides what gets escalated.

Define severity levels. Use three tiers: minor (no external impact, fix and log), significant (customer-visible, may require notification), and serious (legal, safety, or fundamental rights impact, requires authority notification). Write one paragraph per tier with examples from your own systems.

Create a response checklist. When an incident is detected, the owner should:

  • Freeze or isolate the affected AI system
  • Document what happened, when, and who was affected
  • Assess severity against your tier definitions
  • Decide on internal and external communication
  • Log the incident and the corrective action

Train frontline staff. Customer service and sales teams are often the first to hear about AI failures. They need to know what to escalate and to whom.

Review quarterly. Look at incident logs for patterns. One-off glitches are noise. Recurring failures are signals that a model or workflow needs redesign.

What SMEs Should Do Before the Regulator Calls

The EU AI Act’s enforcement timeline is not abstract. National authorities are already building capacity. The Reuters hook signals that questions about disclosure duties are moving from academic debate to practical enforcement. SMEs that wait for a fine or a customer lawsuit to build incident response will pay more than those that start now.

Three immediate actions:

  1. Inventory your AI systems. List every tool that makes decisions or interacts with customers, including ones you bought from vendors.
  2. Map each system to a risk tier using the Act’s categories. Most SME tools will be minimal or limited risk, but do not assume.
  3. Draft a one-page incident response policy. Keep it short enough that your team will actually read it.

The goal is not perfection. It is demonstrable effort. Regulators and courts look more favorably on companies that can show they tried to catch and fix problems than on companies that claim nothing ever goes wrong.

The Trust Dividend of Transparency

Disclosure is not only about compliance. It is a competitive signal. When an SME tells a client, “Our AI flagged your order as fraudulent, we reviewed it manually, and here is what we changed,” that client sees competence. When an SME hides the same event and the client discovers it later, the relationship often ends.

Transparency about AI incidents is becoming a market differentiator, especially for SMEs selling to larger enterprises. Procurement teams at big companies increasingly ask vendors to describe their AI governance. A clean, documented incident log is a sales asset.

The question is no longer whether to prepare for AI incident disclosure. It is whether you will prepare before an incident forces your hand. Will your next AI failure be a quiet lesson logged in a file—or a public story you did not control?


Prefer to keep your data on your own servers? Everything in this article also works with a private, self-hosted AI - no customer data sent to the cloud. Learn more about private AI for business.

Want to implement AI in your company?

Request a free demo and discover how we can help you.

Request Free Demo