AI-Ready or Audit-Ready? What SMEs Must Build Before the EU AI Act Deadline
EU AI Act obligations are becoming practical infrastructure questions for SME deployers. Build the minimum operating layer: AI inventory, logging, oversight paths, and incident runbooks.

Contents

EU AI Act obligations are becoming practical infrastructure questions for SME deployers. Build the minimum operating layer: AI inventory, logging, oversight paths, and incident runbooks.
Share this article
The August Moment Most Businesses Are Not Ready For
Picture a 42-employee logistics company in Munich. Managing director Clara has been running a digital customer-service strategy for two years. Her team handles around 180 customer inquiries per day. Tom Krause, the IT lead, manages the systems. Sarah Meier in dispatch uses AI-assisted route planning. In sales, an AI assistant drafts proposals that a team member approves. A chatbot answers first-line customer questions. A CRM AI feature classifies leads. And an internal document-retrieval system supports accounting.
In July 2026, a larger customer sends a supplier audit questionnaire. One question asks: "Please document all AI systems you use, including purpose, human oversight, logging approach, and incident handling."
Clara forwards it to Tom. Tom knows the helpdesk chatbot, but not the CRM AI that sales turned on themselves. Sarah knows the route planner uses AI, but cannot say what customer data flows to the provider. Finance sees invoices for five different AI tools, but no risk classifications. Nobody has a complete AI inventory. The company uses six AI-powered systems every day, but cannot explain its AI operations.
This is where the EU AI Act becomes operational for SMEs. The deadline is not the moment to become compliant. It is the moment when the presence or absence of your compliance infrastructure becomes visible to customers, partners, and eventually authorities.
The headlines often sound bigger than the first practical step. Most small and medium-sized companies are not providers of general-purpose AI models. They are deployers: they operate AI-enabled tools inside their own business processes. That does not make the work trivial, but it makes it concrete. You do not need to document OpenAI's model internals. You need to know which AI systems you operate, why you use them, who supervises them, and what evidence they leave behind.
The Bitkom study "Artificial Intelligence in Germany 2026" reports that 41 percent of German companies actively use AI — more than double the 17 percent recorded in 2024. At the same time, 53 percent cite legal uncertainty as the biggest obstacle. For these mid-market businesses, the regulation becomes practical as soon as customers or authorities ask for evidence.
The timeline needs careful wording. Article 4 on AI literacy has applied since February 2, 2025. Transparency duties under Article 50 become relevant from August 2, 2026; under the May 7, 2026, Digital Omnibus political agreement, some provider-side synthetic-content marking duties would move to December 2, 2026. Full Annex III high-risk obligations are expected to move to December 2, 2027, under the same agreement. Before publication, the final adopted text should be checked against this draft.
For operators, the practical conclusion is stable: the extension is not a reason to wait. It is time to build a lean, auditable AI operating layer.
Compliance Starts With Architecture, Not Paperwork
Many companies treat regulation as a document problem first. They want a policy, a training deck, maybe a spreadsheet. That is understandable, but not sufficient. You cannot document an AI system that leaves no operational trace. You cannot prove human oversight if the workflow never defines who intervenes and when. You cannot report an AI incident if nobody can identify one.
The EU AI Act therefore creates an architecture question: what operating system does a company need so AI inventory, data flows, classification, logging, oversight, and incidents are visible?
For deployers of high-risk AI systems, Article 26 is the relevant anchor. It includes obligations to use the system according to provider instructions, assign natural persons with competence, training, and authority for human oversight, keep automatically generated logs for at least six months, report serious incidents to the provider, and inform affected workers where AI systems are used in decisions affecting them.
One correction matters: these deployer obligations sit in Article 26, not Article 29. Article 29 concerns applications by conformity assessment bodies. A company building its governance layer should get the article references right because inaccurate references create the same uncertainty compliance is meant to reduce.
The gap is rarely "we have not heard of the law." The gap is: we cannot demonstrate what we do in daily operations. There is no register. There is no written classification rationale. Oversight exists as a department name, not as a named person with authority in the process. Logs may exist in a vendor console, but not under the company's control. The incident-response plan covers cybersecurity, but not discriminatory, incorrect, or dangerous AI outputs.
The IAPP analysis of deployer evidence gaps names five typical gaps SMEs fail to notice: no AI system register, no written classification rationale, oversight at department level rather than as a named individual, log retention without a specific AI link, and a generic incident-response plan instead of an AI-specific escalation path.
That is why Planfold frames AI compliance as an operating model. Plan means mapping the AI surface. Unfold means building logging, runbooks, and oversight into workflows. Resonate means maintaining evidence, not just intent.
The Real Cost Of The Infrastructure Gap
The most expensive compliance work is usually not the first build. It is retrofitting under pressure. When a customer, partner, or authority asks which AI systems you operate, a company without a register starts detective work across invoices, SaaS accounts, API keys, browser extensions, CRM features, and private test tools.
A realistic scenario looks like this: a company tries to reconstruct an AI inventory for a procurement questionnaire. Finance exports SaaS spend. IT checks API keys. Marketing identifies a content tool. HR reports an AI feature used for candidate pre-screening. Operations has a small automation with an LLM node. Several days later, the list is still uncertain because nobody knows what was tested, what is productive, and what has access to personal data.
That "several days" frame is illustrative, not a sourced statistic. The operating point is simple: a maintained register answers these questions quickly. A reconstructed register creates uncertainty when trust is needed.
The penalties are visible, but they are not the whole business risk. The EU AI Act includes maximum penalty bands of EUR 35 million or 7 percent of global annual turnover for prohibited practices, EUR 15 million or 3 percent for certain high-risk non-compliance, and EUR 7.5 million or 1 percent for supplying incorrect information. For SMEs and small mid-caps, proportionate caps and simplified documentation are part of the Digital Omnibus direction.
For many companies, procurement pressure will arrive earlier than formal enforcement. Larger customers already ask suppliers for AI governance evidence. Germany's NIS2 implementation has also created stronger incident, risk management, and supply-chain expectations for covered organizations since December 2025. AI governance, NIS2 operations, and data sovereignty can share one infrastructure layer: registers, owners, logs, runbooks, and retrievable evidence.
The Compliance Infrastructure Map
A useful AI compliance layer does not have to start as a heavy GRC platform. For SMEs and startups, the minimum model is often a five-layer stack that lives inside the digital headquarters. Each layer must perform an operational job rather than exist as a static document.
The map below shows the practical sequence: inventory at the base, then classification and ownership, then logging, then human oversight, then incident runbooks and review routines. On the right is the Planfold sequence: Plan for inventory and classification, Unfold for logging and oversight, Resonate for incident learning and continuous review.

AI Inventory Layer: Know What You Operate
An AI inventory is not a purchasing list. It is a living register: system name, vendor, version or tier, purpose, business process, data touched, risk classification, classification rationale, provider evidence, assigned owner, logging status, oversight path, and last review date.
Start pragmatically with invoices and API keys. Anything you pay for, anything with embedded AI capability, and anything connected to an AI provider through a key belongs on the candidate list. Then check whether it is used in production, what data it processes, and whether it affects a consequential decision.
The Cloud Security Alliance analysis of high-risk AI systems examined 106 enterprise AI systems and found 18 percent clearly fell under Annex III, while 40 percent had unclear classification. That uncertainty is exactly why a documented register matters: the "high-risk or not" decision must be traceable.
Logging And Observability: Evidence Instead Of Memory
Article 26 requires deployers of high-risk AI systems to keep automatically generated logs for at least six months unless another law requires longer retention. For non-high-risk systems, logging is still good operating discipline whenever AI prepares decisions, processes customer data, or generates public-facing output.
Implementation can vary. An n8n workflow with an AI node can expose prompt, response, failure state, and downstream action through execution history. A custom API can route AI calls through a logging gateway. A database-backed process can keep audit tables for AI-assisted decisions. The important question is not the tool. It is retrieval: can you show what happened in a named process over the last six months?

Human Oversight And Override Paths
"A human can always intervene" is not an oversight model. For deployers, the evidence needs to be more specific: who is responsible, what competence and authority do they have, when is review triggered, how can an AI output be paused or overridden, and where is the intervention recorded?
A useful one-page runbook per AI process answers six questions: which system is affected, who is the named oversight person, what counts as abnormal or suspect output, who can pause or override the system, where the decision is recorded, and what happens if the named person is unavailable.
From Scattered AI Tools To A Governed Operating Layer
Before governance, AI adoption often looks similar across companies. Marketing uses a content tool. Sales turns on an AI feature in the CRM. HR tests a screening assistant. Operations builds a small automation with an LLM step. Each local decision seems reasonable. Together they create shadow AI: distributed data flows, unclear ownership, and unknown risk.
In that state, the company cannot reliably answer basic questions. Which AI systems process personal data? Which ones assist decisions about people? Who supervises each output? Which provider terms apply? What would we do if an output were discriminatory, incorrect, or publicly misleading?
After governance, the operating model looks different. Every AI system is in the register. Every classification has a rationale. Consequential processes have logs. Oversight paths are named. Incidents flow into a runbook. New tools are not banned by default; they are evaluated through the same model: purpose, data, risk, logging, oversight, and exit path.
The difference is not bureaucracy. The difference is speed under scrutiny. When a customer asks whether an AI tool processes personal data, the team does not need to interview three departments. When an AI workflow fails, the owner is visible. When a new tool is proposed, it is assessed against the same operating criteria instead of by instinct.
How Planfold Frames AI Compliance Infrastructure
Planfold does not treat AI compliance as a standalone legal project. The better question is: what digital machine does the company need so AI becomes useful, explainable, and operable?
Planfold builds this machine on Kubernetes platforms with DACH hosting. Our team holds CKA and CKAD certifications and operates n8n automations for logging checks, register maintenance, and review routines. The governance layer therefore runs on the same sovereign infrastructure that already carries other business processes — not as a separate compliance portal, but as part of the digital headquarters.
Plan means mapping the AI surface. Which systems are in use? Which business processes do they touch? Which data flows are involved? Which applications need an Article 50 transparency check? Which could be Annex III relevant? Which are probably lower-risk, but still need logging because they touch customers or decisions?
Unfold means building the governance layer. A first register, a logging path, an oversight runbook, an incident path. Not as a separate compliance portal, but inside the digital headquarters: workflows, documentation, roles, databases, and automation.
Resonate means maintaining evidence. Monthly register review. Quarterly log-retrieval test. Review of AI-specific incidents. Classification updates when a system changes. These routines are quiet, but they prevent compliance from becoming memory and assumption six months later.
A Practical Starting Point For SMEs And Startups
If you are not sure where to begin, choose one AI process that touches customer data or prepares a consequential output. Not the most impressive use case. The one where transparency, oversight, and failure paths matter.
Block two hours. Write the process as a simple chain: input, AI step, output, human review, action, log, possible incident. Then add the operational details for each step: data source, owner, system, evidence, fallback.
The result does not need to be perfect. It needs to be repeatable. One well-documented AI workflow with logging, oversight, and a runbook is a better starting point than a 40-page policy nobody uses in daily operations.
Then apply the pattern to the next process. CRM AI. Support chatbot. Document automation. Internal knowledge search. Routing optimization. Not all at once, but layer by layer.

The Outcome: A Business That Can Explain Its AI
For most SMEs, the EU AI Act is not a reason to stop using AI. It is a reason to operate AI more maturely. Companies that build an inventory, a logging layer, clear oversight paths, and incident runbooks in 2026 will react with less panic in 2027. They can answer customer questions faster, evaluate new AI tools more cleanly, and distribute internal responsibility more clearly.
This is also the stronger sovereignty position. You keep the exit key because AI operations do not disappear into an opaque tool mix. You can change vendors, explain processes, and retrieve evidence without reconstructing the digital machine from scratch every time.
Planfold's care-free package does not mean promising legal compliance. It means building and operating the practical foundation on which compliance can become demonstrable. Plan. Unfold. Stay Sovereign.


