EU AI Act deadlines for SMBs after the 2026 reset

The EU AI Act did not disappear in August 2026. It split into a set of duties that apply now and a larger high-risk package that moved later. For a small or midsize business, the immediate work is usually much narrower than a full conformity program: identify how the company uses AI, stop any prohibited use, put the required notices on customer-facing and published output, and preserve the evidence behind those decisions.

The confusion is understandable. The original regulation made 2 August 2026 its general application date. Then the AI Omnibus entered into force on 27 July 2026, less than a week before that date, and postponed the main high-risk rules. That late change did not postpone Article 50 transparency duties, erase the rules already active since 2025, or exempt a company because it has 40 employees instead of 4,000.

This is operational guidance for founders and managers, not a substitute for advice on a disputed classification or a regulated product. The sensible target is a defensible inventory and a short decision record, not a binder copied from a large-company compliance manual.

What actually changed in August 2026

The immediate change is simple: transparency rules started on 2 August 2026, while most high-risk requirements now start on 2 December 2027 or 2 August 2028. The extra time applies to the high-risk package, not to every part of the Act.

The European Commission's July notice on the AI Omnibus gives the revised dates. Annex III systems, which cover listed uses in employment, education, access to essential services, biometrics and several public-sector fields, move to 2 December 2027. High-risk AI that is a product or safety component under Annex I, such as certain machinery or medical-device software subject to third-party conformity assessment, moves to 2 August 2028.

The delay exists because CEN and CENELEC had not finished the harmonised standards on the original schedule. The Commission says those voluntary standards will give providers a presumption of conformity when they cover the relevant requirement. Moving the date is therefore material for a startup building a recruitment system or regulated device. It is not permission to ignore the use case until the night before enforcement.

Several obligations were already live before this month:

• The definition of an AI system and the prohibited-practices rules have applied since 2 February 2025.
• The AI literacy provision has applied since 2 February 2025, although the Omnibus simplified how it operates and shifted more support work to the Commission and Member States.
• Governance rules and obligations for providers of general-purpose AI models have applied since 2 August 2025.
• The AI Office can enforce the general-purpose model rules from 2 August 2026, including against older models whose transition ended then.

And one new group applies now. Article 50 requires notices for certain human interactions, machine-readable marking by providers of generative systems, and disclosure by deployers in specified uses. A pre-August generative system gets a limited transition until 2 December 2026 only for the provider's machine-readable marking duty. That exception does not postpone every transparency obligation, and old content does not need retroactive labels merely because it was generated before 2 August.

Do not write “AI Act delayed until 2027” in a board memo. Write which provision applies to which system and on which date. That single habit prevents most bad decisions in this area.

Scope follows the market and use, not company size

An SMB is in scope when it supplies an AI system or general-purpose model to the EU market, puts an AI system into service in the EU, uses one in the EU, or falls within the Act's rule for output used in the EU. Incorporation in Delaware, London or Singapore does not settle the issue.

The Act covers public and private actors. The Commission's “Navigating the AI Act” guidance describes providers, deployers, importers and distributors, and it expressly says the framework reaches actors inside and outside the EU. A US software company that offers an AI recruiting product to German employers can be a provider in scope. A German retailer that buys the product to filter applicants can be a deployer. Both may have duties, but they do not have the same duties.

Company size affects proportionality and some relief. It does not create a general exemption. Under Article 99, the maximum fine for an SME uses the lower of the stated euro amount and turnover percentage, rather than the higher figure used for larger companies. Authorities must consider proportionality and economic viability. That is useful protection against a ruinous arithmetic result, not a license to skip disclosure.

The practical scope questions are these:

1. Does the software meet the Act's AI-system definition, rather than merely running fixed rules written by a person?
2. Are you the provider, deployer, importer, distributor, product manufacturer, or more than one of them?
3. Is the system or model offered, put into service, or used in the EU, or is its output intended for use there?
4. Does an exclusion cover the activity, such as qualifying pre-market research and prototyping, military or national-security use, or strictly personal non-professional use?
5. Does another EU or national law still apply even if the AI Act does not add a duty?

That last question catches teams that celebrate too early. An ordinary sales assistant may sit in the AI Act's minimal-risk bucket, yet its processing can still trigger GDPR, consumer law, employment law, confidentiality duties, or sector rules. “Not high-risk under the AI Act” does not mean “unregulated.”

A vendor contract does not transfer your role

Buying access to a well-known model normally makes the buyer a deployer of that system. But putting a system on the market under your own name, changing its intended purpose, or making a substantial modification can move provider obligations onto you. A contract clause that calls the vendor “the provider” cannot override what the parties actually do.

Consider an HR startup that connects a third-party model to applicant records, adds its own ranking logic, and sells the result as its candidate-screening product. It may deploy the underlying model while acting as provider of the finished AI system. Treating the whole stack as “we just use an API” misses the marketed system and the employment purpose that drive classification.

Most internal AI use is not high-risk

Routine use of writing assistants, coding tools, meeting transcription, search, translation and customer-support drafting is usually not high-risk merely because a model produced the output. Risk level follows intended purpose and context, not how impressive the model seems.

The Commission describes two high-risk routes. Under Article 6(1), AI is high-risk when it is a product or safety component covered by listed EU product legislation and that product requires third-party conformity assessment. Under Article 6(2), the intended use appears in Annex III. Annex III includes specified uses in biometrics, critical infrastructure, education, employment, access to essential private or public services, law enforcement, migration, justice and democratic processes.

For a typical SMB, employment is the most common trap. AI used to place targeted job ads, filter applications, evaluate candidates, decide promotions or terminations, allocate tasks based on personal traits, or monitor and evaluate worker performance can fall within Annex III. A tool that merely formats a job description is different from one that ranks people. A meeting summarizer is different from a tool that infers whether an employee is engaged.

Creditworthiness for natural persons and risk or pricing for life and health insurance also appear in the listed uses. A fraud-detection tool can require a closer reading because the Act treats some protective fraud uses differently from a system that decides whether a person receives an essential service. Labels such as “recommendation engine” or “decision support” do not change the intended purpose.

Annex III has a narrow escape in Article 6(3) for a listed system that does not pose a significant risk to health, safety or fundamental rights and does not materially influence decision-making. The conditions include limited procedural or preparatory tasks, improving a completed human activity, detecting decision patterns without replacing the human assessment, or performing a preparatory task. Profiling natural persons blocks that escape. A provider relying on the exception must document the assessment. The safe conclusion is not that every low-impact HR feature is high-risk, but that the exception needs facts and a written rationale.

The postponement gives providers and deployers time before the high-risk operational duties apply. Providers will eventually face risk management, data governance, technical documentation, logging, instructions, human oversight design, accuracy, cybersecurity, quality management, conformity assessment and registration duties. Deployers will need to follow instructions, assign equipped human oversight, monitor use, keep relevant logs under their control, respond to incidents and give required notices. Some deployers also need a fundamental-rights impact assessment.

You should classify now because design and contract choices made in 2026 determine whether compliance in 2027 is cheap or painful. You do not need to claim conformity eighteen months early. You do need to know whether a product roadmap is quietly building an employment or credit-decision system.

Transparency duties are live now

Article 50 now applies to four practical situations: direct interaction with AI, synthetic-content marking by a provider, emotion recognition or biometric categorisation, and specified public disclosures by a deployer. SMBs are more likely to encounter these duties than the high-risk conformity rules this year.

First, a provider of an AI system designed to interact directly with people must ensure that people know they are interacting with AI, unless that is obvious to a reasonably informed and attentive person in the context. Put the notice where the interaction begins. Hiding “AI may be used” in terms of service is weak because the user needs the information during the interaction.

Second, providers of systems that generate synthetic audio, images, video or text must make the output machine-readable and detectable as artificially generated or manipulated, as far as technically feasible. The law considers the content type, implementation cost and available technical methods. It excludes systems that only assist standard editing or do not substantially change the input or its meaning. This is a provider duty built into the system, not a caption that every employee must manually paste.

Third, a deployer using emotion recognition or biometric categorisation must inform exposed people. Some uses are prohibited outright, including emotion recognition in workplaces and schools except for medical or safety reasons. A disclosure cannot rescue a banned use.

Fourth, deployers must visibly disclose deepfakes. They must also disclose AI-generated or manipulated text published to inform the public on matters of public interest when it lacks human review or editorial control and no person or company holds editorial responsibility. The editorial exception matters. A founder who uses AI for a first draft, verifies every claim, rewrites the argument and accepts responsibility is not in the same position as an automated feed that publishes model output untouched. Keep evidence of the review instead of relying on a vague “human in the loop” claim.

The disclosure must be clear and distinguishable by the first exposure, while respecting accessibility. The Commission published Article 50 guidelines in July 2026 and a voluntary Code of Practice on Transparency of AI-Generated Content in June. The code is not the law, but a company that follows it has a more concrete way to explain its marking and labelling choices. A non-signatory can use other adequate measures and should be ready to document them.

For a support chatbot, a usable implementation record can be this small:

system: website-support-assistant
role: provider-and-deployer
eu_exposure: true
article_50_case: direct-interaction
notice: "You are chatting with an AI assistant. A person can review your request."
notice_location: before-first-message
owner: support-operations
reviewed: 2026-08-03
evidence: screenshot-and-release-id

The file does not prove compliance by itself. It forces an owner to connect the legal case to the shipped notice, location, date and release. That is far better evidence than a spreadsheet cell marked “done.”

Prohibited uses still deserve the first review

Stop prohibited practices before debating whether a system is high-risk, because the ban has applied since February 2025 and carries the Act's highest penalty tier. Most small companies will find no prohibited use, but a short targeted review is warranted.

The banned list includes harmful manipulation or exploitation that materially distorts behavior and causes or is reasonably likely to cause significant harm, social scoring with the specified detrimental treatment, individual crime-risk prediction based solely on profiling or personality traits, and untargeted scraping of facial images from the internet or CCTV to build recognition databases. It also covers certain biometric categorisation using sensitive traits and emotion recognition at work or school, subject to narrow medical or safety exceptions.

The AI Omnibus added a ban on systems that generate non-consensual sexually explicit or intimate content and child sexual abuse material. This is one of the substantive July changes, not a postponed high-risk requirement.

Do not reduce this review to a vendor questionnaire asking whether a product is “EU AI Act compliant.” Look at configuration and use. A general video-analysis product may be lawful for counting room occupancy and prohibited when a manager turns on an emotion score to judge staff. The same vendor name tells you almost nothing.

The most common recommendation I reject is “ban all generative AI until legal finishes a full assessment.” It is popular because it sounds safe and gives one department control. It usually drives employees into personal accounts, removes visibility, and spends review time on low-impact drafting while a recruitment plugin keeps scoring applicants. Ban the prohibited use, gate the sensitive decisions, and give ordinary users an approved route with clear rules.

A five-line employee rule often works better than a 40-page policy:

• Use only company-approved accounts for company information.
• Do not enter secrets or personal data unless the approved configuration permits it.
• Do not let AI make employment, credit, insurance, health or access decisions without the designated review.
• Verify consequential output and record who approved the final decision.
• Report a new AI tool or use case to the named owner before connecting business data.

This policy does not finish GDPR, security or sector compliance. It creates a control point where the company can see new uses before they become embedded.

Provider and deployer duties must stay separate

The provider builds or has the system built and places it on the market or puts it into service under its name; the deployer uses an AI system under its authority in a professional activity. Many compliance plans fail because they list “AI obligations” without attaching each one to a role.

Suppose a 70-person retailer licenses a customer-service chatbot. The vendor designs the interactive system and must make the AI interaction transparent by design. The retailer deploys it, chooses the knowledge base and escalation process, and remains responsible for its own use, data processing and customer representations. If the retailer substantially modifies the system or rebrands a system it controls as its own product, the role analysis can change.

Now suppose the same retailer uses a model to draft product descriptions. If staff review them before publication, Article 50's public-interest text disclosure rule probably is not the central issue, and product descriptions usually do not inform the public on a matter of public interest. Consumer accuracy, intellectual property and privacy can still matter. A blanket label on every AI-assisted sentence would create noise without answering the actual rule.

Contracts should support the role analysis. Ask for the intended purpose, instructions for use, system version, known limitations, logging options, incident contact, data locations, subprocessors where relevant, and a promise to notify you of changes that affect classification or instructions. For a potentially high-risk system, ask what information the vendor will provide for your oversight, impact assessment, records and explanations to affected people.

Do not accept “the customer is solely responsible for compliance” as an accurate description of the Act. Each operator keeps the obligations assigned to its role. Commercial indemnities can allocate money after a failure, but they do not turn a deployer into a provider or erase a provider's design duty.

General-purpose model providers are a separate group. If your company trains a model and places it on the EU market under its name, the GPAI duties can include technical documentation, information for downstream system providers, a copyright policy, and a public training-content summary. Models with systemic risk carry added evaluation, risk mitigation, incident reporting and cybersecurity duties. A company merely calling a third-party general-purpose model through an API usually does not become the provider of that underlying model, though it can still be provider of the AI system it sells.

A minimal compliance path takes five records

A small business can establish a defensible baseline with five maintained records: an inventory, a role and scope decision, a risk classification, an applicable-controls record, and an evidence log. The work should fit the actual systems rather than the size of the regulation.

1. Inventory systems and uses

Start with business uses, not vendor logos. One model can support a harmless drafting tool and a sensitive candidate ranker. Record an owner, purpose, users, affected people, input data, output, countries, vendor and model, degree of automation, whether a human can override, and where the result goes.

Search purchasing records, single sign-on logs, browser extensions, code repositories and expense claims. Interview HR, support, marketing, sales and engineering. The awkward question is “Which tool would your team keep using if we blocked the approved assistant?” That often finds personal accounts and embedded features faster than a survey.

2. Decide role and EU connection

For each use, record whether the company is provider, deployer, importer or distributor and why. Note the EU connection and any claimed exclusion. If the system is sold under your brand, write down who chose its intended purpose and who can change its behavior.

3. Classify the use

Check prohibited practices first, then the two high-risk routes, then Article 50 cases. Record other regimes that need a separate owner. For Annex III, cite the exact category and whether the Article 6(3) exception is claimed. “Low risk” without reasoning is not a classification.

4. Attach controls and deadlines

Map each live duty to a control, owner and evidence location. Map postponed duties to a preparation date. An Annex III provider that waits until December 2027 to design logging has misunderstood software delivery; logs cannot reconstruct training and production history that the system never kept.

5. Review changes

Review on a schedule and when purpose, model, data, automation, affected group or geography changes. A release that adds applicant ranking is a classification event. So is expanding a US-only service to EU customers.

A compact inventory row can look like this:

{"id":"AI-017","use":"rank inbound job applicants","owner":"people-ops","role":"deployer","eu_use":true,"vendor_system":"external","decision_effect":"shortlist recommendation","human_override":true,"classification":"Annex III employment candidate","live_controls":["approved access","applicant notice","incident route"],"future_controls":["oversight assignment","log retention","use monitoring"],"next_review":"2026-10-01"}

Do not copy the example's classification into your register without checking the actual system. Its purpose is to show the output shape: one row connects a real use to role, geography, decision effect, classification, controls and review.

oleg.is mentions AI transformation in the context of engineering teams, but the same operating discipline applies here: reduce the manual ceremony while keeping explicit ownership and evidence. A Team & AI Audit can identify tools, roles and cost opportunities together, though a lawyer should resolve contested legal interpretations.

Evidence should match the decision, not the template

The minimum evidence is whatever lets a competent outsider reproduce why you classified the system and confirm that the control shipped. A policy without system records is too abstract; screenshots without a decision rationale are too brittle.

Keep the version of the inventory used for the decision, the vendor instructions and relevant contract, the classification note, the deployed notice or marking test, approval records, training material for the people operating the system, incident reports, and review history. Preserve system and release identifiers so evidence can be tied to production.

For human review, name what the reviewer checks and what authority the reviewer has. A recruiter who receives a score but cannot see its basis, change the shortlist, or pause the tool does not supply meaningful oversight. A publisher who clicks “approve” on hundreds of untouched posts does not create credible editorial control. Measure the decision path, not the presence of a human-shaped step.

AI literacy evidence should also follow role. A developer integrating a model needs to understand limitations, testing, logs and failure modes. A recruiter needs to understand what the ranking means, what it misses, how bias can enter, and when to stop using it. An executive needs to know which uses require escalation. One generic video for all employees may document attendance while teaching none of them enough for their job.

Avoid collecting evidence that creates a second privacy or security problem. Store the decision record and test result, not a dump of every prompt containing customer data. Apply retention and access rules. Redact personal data from screenshots when the identity is not part of the proof.

Test notices in the actual user journey. Save a screenshot of the first chatbot screen, a sample output with machine-readable metadata where applicable, the detector result, the release identifier and the test date. For an accessibility check, confirm that the disclosure works with the same assistive methods used for the surrounding service.

The failure pattern is predictable. A company inventories vendors, assigns every one “medium risk,” buys a policy template, and closes the project. Six months later HR enables a candidate-ranking add-on under an already-approved vendor account. The inventory never tracked use or feature changes, so nobody reclassifies it. A useful process attaches review triggers to purpose and configuration, not just annual calendar reminders.

The fine headline is a poor planning tool

The Act permits serious penalties, but an SMB should prioritize by exposure and harm rather than multiplying every use by the maximum fine. The ceiling is not the expected invoice, and different infringements sit in different tiers.

Article 99 sets up to EUR 35 million or 7 percent of worldwide annual turnover for prohibited practices. Other listed operator duties, including Article 50 transparency and high-risk provider or deployer obligations, can reach EUR 15 million or 3 percent. Incorrect, incomplete or misleading information to authorities can reach EUR 7.5 million or 1 percent. For SMEs, including startups, the applicable maximum is the lower of the fixed sum and percentage. Authorities consider the nature, gravity, duration, intent, mitigation, cooperation and other case facts.

Those numbers should stop a founder from ignoring a banned workplace-emotion tool. They should not persuade a ten-person company to spend six months documenting a spelling assistant while leaving applicant screening unexamined.

Prioritize in this order:

1. Stop any potentially prohibited practice and escalate uncertain cases.
2. Fix Article 50 disclosures and provider marking work that applies now.
3. Confirm whether the company provides a general-purpose model and, if so, whether the live GPAI duties are covered.
4. Identify Annex III and regulated-product systems, assign their 2027 or 2028 work, and prevent design debt.
5. Maintain ordinary-use controls for privacy, security, accuracy, contracts and intellectual property.

The last item is not lesser work. It sits last only in an AI Act deadline list. A leaked trade secret or unlawful processing event can matter today even when the system remains minimal risk under this regulation.

What an SMB should do this week

By the end of the week, an SMB should know every material AI use, who owns it, its role, its EU connection, whether a prohibition or Article 50 duty applies, and whether it belongs on the 2027 or 2028 plan. If that sounds like a large transformation, the company has probably scoped the first pass too broadly.

Set a two-hour session with the people who own HR, customer support, marketing, product and engineering. Bring the purchasing and account lists. Record uses in the five-record structure above. Give each uncertain employment, biometric, credit, health, insurance or public-interest use a named reviewer and a decision date.

Ship obvious disclosures immediately. Put the chatbot notice before the first message. Verify whether your generative product embeds machine-readable marks and whether the transition to 2 December applies. Label covered deepfakes and automated public-interest text at first exposure. Do not label ordinary edited drafts reflexively just to avoid classification work.

Then create one change gate in the existing procurement or release process: no new AI purpose, affected group, decision authority, model or EU launch without updating the record. This control costs little and catches the changes that turn a low-impact feature into a regulated use.

Reserve legal advice for the decisions where text and facts genuinely collide: Article 6(3) exceptions, substantial modifications, provider status in a branded stack, public-interest publishing, product-safety classification, or overlapping employment and data-protection duties. Send counsel a completed fact record. Paying a lawyer to discover which tool HR uses is an expensive way to build an inventory.

The August reset gave high-risk providers more implementation time. Use that time to preserve design evidence and negotiate usable vendor information. For everything already live, the grace period has ended or is narrow. The next concrete move is to open the chatbot, recruiting workflow and publishing pipeline as a user would, and compare what happens with the classification record. Any gap you can see on screen is more urgent than another policy draft.