Forem: Oleksandr Usenko

You Didn't Build the AI — You're Still Liable: Deployer Obligations Under the EU AI Act

Oleksandr Usenko — Mon, 23 Feb 2026 12:43:03 +0000

The Uncomfortable Truth About Third-Party AI

There is a widespread misconception circulating in European boardrooms right now: "We don't build AI, so the AI Act doesn't really apply to us."

This is wrong, and it could be an expensive mistake.

The EU AI Act distinguishes between providers (those who develop or place AI systems on the market) and deployers (those who use AI systems under their authority). If your company uses ChatGPT for customer support, Microsoft Copilot for document drafting, an AI-powered applicant tracking system for hiring, or any SaaS product with embedded AI features — you are a deployer. And deployers have real, enforceable obligations under the EU AI Act starting August 2, 2026.

The penalty for getting this wrong? Up to €15 million or 3% of global annual turnover, whichever is higher.

What Exactly Is a "Deployer"?

Article 3(4) of the EU AI Act defines a deployer as any natural or legal person that uses an AI system under its authority, except where the AI system is used in the course of a personal non-professional activity.

This definition is deliberately broad. You become a deployer the moment your organization uses an AI system in a professional context — regardless of whether you built it, bought it, or simply signed up for a free tier.

Some examples that make companies deployers without them realizing it:

Using AI-powered recruitment tools like HireVue, Pymetrics, or any ATS with AI screening — this is likely high-risk AI under Annex III
Deploying AI chatbots for customer service, even if they run on GPT-4 or Claude under the hood
Using AI credit scoring or fraud detection tools provided by your fintech vendor
Running AI-assisted medical diagnostics through third-party software in clinical settings
Applying AI for employee monitoring or performance evaluation through HR platforms

In each case, the AI provider has their own set of obligations. But that does not eliminate yours.

The Five Core Deployer Obligations

Here is what the EU AI Act actually requires from deployers of high-risk AI systems. These are not suggestions — they are legally binding requirements.

1. Use the System According to Instructions

Article 26(1) requires deployers to use high-risk AI systems in accordance with the instructions of use provided by the provider. This sounds trivial, but it has teeth.

If your provider's documentation says their AI hiring tool should only be used as a screening aid with human review of all decisions, and your HR team starts auto-rejecting candidates based solely on AI scores — you are in violation. The provider documented the intended use. You deviated from it. The liability is yours.

Practical step: Obtain and actually read the instructions of use for every AI system your organization deploys. Store them centrally. Ensure the people operating these systems know the documented boundaries.

2. Assign Human Oversight

Article 26(2) requires deployers to assign human oversight of high-risk AI systems to individuals who have the competence, training, and authority to fulfil that role.

This means someone in your organization must be specifically responsible for monitoring each high-risk AI system's operation. That person needs to understand how the system works at a functional level, be trained on what to watch for, and have the actual authority to override or stop the system when something goes wrong.

A common failure mode: companies designate a junior employee who technically "monitors" the AI system but has no authority to intervene when it produces questionable outputs. This does not satisfy the requirement.

Practical step: For each high-risk AI system, formally document who provides human oversight. Verify they have appropriate training and decision-making authority. This should be part of your AI governance framework.

3. Ensure Input Data Quality

Article 26(4) states that deployers who exercise control over the input data must ensure that input data is relevant and sufficiently representative in view of the intended purpose of the high-risk AI system.

If your AI credit scoring tool takes customer data that you collect and manage, you are responsible for the quality and representativeness of that data. Feeding the system incomplete, biased, or outdated data is your liability, not the provider's.

Practical step: Audit the data pipelines feeding your high-risk AI systems. Document what data goes in, where it comes from, how it is cleaned, and whether it adequately represents the population the system will affect.

4. Monitor Operation and Report Issues

Article 26(5) requires deployers to monitor the operation of high-risk AI systems based on the instructions of use and, when relevant, inform providers or distributors about serious incidents or malfunctions.

You cannot simply deploy an AI system and forget about it. You need ongoing monitoring — checking whether the system performs as expected, whether its outputs remain within acceptable bounds, and whether any patterns suggest drift, bias, or malfunction.

When something goes wrong, you have a legal obligation to report it. If you discover a serious incident — meaning an incident that results in death, serious damage to health, serious disruption to critical infrastructure, or serious harm to property or the environment — you must report it to both the provider and the relevant market surveillance authority. The timeline for this reporting is tight: you need to act as soon as you establish a causal link between the AI system and the incident.

Practical step: Establish a monitoring protocol for each high-risk AI system. Define what "normal operation" looks like and what triggers an investigation. Create an incident reporting process before you need one.

5. Conduct a Fundamental Rights Impact Assessment

Article 27 requires certain deployers — specifically public bodies and private entities providing public services — to carry out a fundamental rights impact assessment (FRIA) before deploying high-risk AI systems.

Even if your organization is not legally required to conduct a FRIA, doing one is good practice. It forces you to think systematically about who your AI systems affect, what could go wrong, and what safeguards are in place. Regulators will likely view a voluntary FRIA favorably if questions arise about your compliance posture.

Practical step: Use the risk assessment frameworks relevant to your sector. Document your assessment and keep it updated as your use of the AI system evolves.

Transparency Obligations Apply to All Deployers

Even if your AI systems are not classified as high-risk, you still have transparency obligations under Article 50.

If you deploy an AI system that interacts directly with people — a chatbot, a virtual assistant, an AI phone agent — you must inform those people that they are interacting with an AI system. The exception is only when this is "obvious from the circumstances and the context of use," which is a higher bar than most companies assume.

If you use AI to generate or manipulate images, audio, or video content (deepfakes or synthetic media), you must disclose that the content was AI-generated. This applies even to marketing materials that use AI-generated imagery.

Practical step: Audit every customer-facing AI touchpoint. Implement clear, visible disclosures. "This conversation is powered by AI" is a reasonable starting point for chatbots.

The Supply Chain Problem

Here is where things get genuinely difficult for deployers: you are dependent on your AI providers for much of the information you need to fulfil your own obligations.

To comply with your deployer obligations, you need:

Instructions of use from the provider
Information about the system's intended purpose and limitations
Details about the training data (at least at a high level)
Technical documentation sufficient to understand how the system works
Information about the system's accuracy, robustness, and cybersecurity measures

The AI Act places obligations on providers to supply this information. But in practice, many AI vendors — especially larger ones — are still working out how to deliver this documentation in a usable format. Some SaaS providers with embedded AI features may not even have classified their systems under the AI Act yet.

This creates a real problem: your compliance depends partly on your vendors' compliance.

What to do about it:

Audit your vendor contracts now. Do they include AI Act compliance commitments? If not, negotiate amendments before August 2026.
Request documentation proactively. Ask vendors for their AI Act compliance documentation, intended use descriptions, and risk classifications. If they cannot provide it, that is a red flag.
Build contract language that requires vendors to notify you of material changes to their AI systems, provide updated documentation, and cooperate in the event of regulatory inquiries.
Have a contingency plan. If a critical vendor cannot demonstrate compliance, you need to know your alternatives. Switching AI tools under regulatory pressure is far worse than planning ahead.

The AI Literacy Requirement Hits Deployers Too

Article 4 of the EU AI Act — which has been enforceable since February 2025 — requires deployers to ensure that their staff and other persons dealing with the operation and use of AI systems on their behalf have a sufficient level of AI literacy.

This is not a vague aspiration. It is an enforceable obligation, and it already applies today.

For deployers, AI literacy means your people need to understand what the AI systems they work with actually do, what their limitations are, and how to interpret their outputs appropriately. A recruiter using an AI screening tool needs to understand that the tool's scores are probabilistic, not deterministic. A loan officer using AI credit scoring needs to understand that the system can produce biased outcomes if not properly monitored.

Generic "AI awareness" training does not satisfy this requirement. The training needs to be tailored to the specific AI systems your people use and the context in which they use them.

Practical step: Build an AI literacy program tied to the specific AI tools your organization deploys. Document the training, track completion, and update it when systems change.

Five Months Left: What to Do Now

The August 2, 2026 deadline is approximately five months away. If your organization has not started addressing deployer obligations, here is a practical prioritization:

Month 1: Inventory
Complete an AI systems inventory. Every AI system your organization uses, including embedded AI in SaaS tools. Classify each by risk level.

Month 2: Gap analysis
For each high-risk system, map your current practices against the five deployer obligations above. Identify the gaps.

Month 3: Vendor engagement
Contact every AI vendor supplying high-risk or significant AI systems. Request their compliance documentation. Begin contract negotiations where needed.

Month 4: Implementation
Implement human oversight assignments, monitoring protocols, incident reporting processes, and data quality procedures for high-risk systems. Roll out AI literacy training.

Month 5: Verification
Test your processes. Run a tabletop exercise simulating a regulatory inquiry. Verify your documentation is complete and accessible. Conduct an internal compliance check.

This timeline is tight but achievable for organizations that commit resources to it. If you have already started, you are ahead of the majority — research suggests only 18% of organizations have fully implemented AI governance frameworks despite widespread operational AI use.

The Bottom Line

Using third-party AI does not insulate you from regulatory responsibility. The EU AI Act was deliberately designed to create accountability across the entire AI value chain — from the company that builds the model to the organization that deploys it to make decisions affecting real people.

The good news is that deployer obligations, while real, are manageable. They boil down to: know what AI you use, use it properly, watch it carefully, keep records, and make sure your people understand what they are working with.

The bad news is that "we assumed our vendor handled all of that" will not be an acceptable answer when a market surveillance authority comes asking questions.

Need help mapping your deployer obligations? AktAI helps organizations identify, classify, and manage their AI compliance requirements — including the deployer-specific obligations that most compliance tools overlook. Start with a free assessment.

EU AI Act Serious Incident Reporting: A Practical 15-Day Playbook

Oleksandr Usenko — Sun, 22 Feb 2026 17:01:16 +0000

When teams discuss EU AI Act readiness, they usually focus on classification, documentation, and conformity assessment. But one of the hardest obligations in practice is operational: what happens when something goes wrong in production.

Article 73 requires providers of high-risk AI systems to report serious incidents to market surveillance authorities, with strict time windows (up to 15 days, and faster in severe cases). For many organizations, that is not mainly a legal drafting issue. It is a detection, escalation, and evidence-preservation issue.

This guide is a practical playbook for building a reporting process that works under pressure.

What Article 73 Actually Requires (in plain terms)

From the legal text and Service Desk publication, the main requirements are:

Report serious incidents to the market surveillance authority in the Member State where the incident occurred.
Report immediately after establishing a causal link (or reasonable likelihood), and no later than 15 days after awareness.
Report within 2 days for widespread infringement / very severe incident categories.
Report within 10 days in case of death.
Initial incomplete reports are allowed, followed by complete reporting.
Investigate without delay, cooperate with authorities, and avoid altering evidence in ways that could compromise later evaluation.

Sources:

European Commission AI Act Service Desk, Article 73: https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-73
Consolidated AI Act text (Article 73): https://artificialintelligenceact.eu/article/73/

Why companies miss deadlines (even when they know the law)

In preparation audits, the same operational gaps appear repeatedly:

No incident taxonomy for AI-specific harm

Security teams have incident classes; product teams have bug severity; legal has regulatory risk. They are not aligned.
No trigger owner

Teams debate whether the issue is “serious enough” while the reporting clock is running.
Evidence gets overwritten

Logs are rotated, models are hot-patched, or prompts are not preserved in reproducible form.
Cross-border confusion

Teams do not know which Member State authority should receive first notice when users are in multiple countries.
Provider vs deployer ambiguity

Contracts do not clearly define who notifies and who supplies supporting facts.

The result is predictable: delayed notification, incomplete documentation, and inconsistent narratives across legal, engineering, and customer-facing teams.

A realistic 15-day playbook

Below is a pragmatic sequence you can implement now.

Day 0 (first awareness): stabilize and preserve

Objective: avoid evidence loss and establish accountable ownership.

Appoint an incident lead (name, backup, and on-call path).
Open a dedicated incident record with immutable timestamps.
Preserve relevant artifacts immediately:
- model version and configuration
- prompts/inputs and outputs (where lawful and available)
- human-oversight actions and overrides
- logs, alerts, user complaints, and rollback actions
Freeze non-essential changes to affected components until legal/technical review confirms safe handling.

Critical principle: do not wait for perfect causality proof before opening the case. You can submit an initial incomplete report later if needed.

Day 1–2: classify severity and reporting clock

Objective: determine if Article 73 thresholds are likely met.

Apply a pre-defined seriousness matrix (harm impact × scale × reversibility × affected rights/safety).
Decide whether the incident could fit:
- standard serious incident (up to 15 days)
- widespread/severe category (2 days)
- death-related incident (10 days)
Record rationale for classification decisions, including dissenting views.

If threshold is plausibly met, prepare draft notification immediately. Over-reporting with clear uncertainty notes is generally safer than late reporting after internal debate.

Day 2–5: submit initial notification (if needed)

Objective: meet timing while facts are still emerging.

A strong initial report should include:

system identity and intended purpose
incident date/time window and discovery path
known/potential harm profile
affected geography / Member State context
current containment actions
known data gaps and expected follow-up timeline

Article 73 explicitly allows incomplete initial reporting, provided follow-up is timely and substantive.

Day 5–10: investigate and update

Objective: move from hypothesis to defensible cause analysis.

Run technical root-cause analysis (data drift, edge case, oversight failure, integration issue, etc.).
Quantify affected population and confidence intervals.
Validate whether corrective actions reduce recurrence risk.
Coordinate messaging so regulatory, legal, and customer communications are factually consistent.

If death-related criteria apply, ensure the 10-day deadline is handled as a hard stop.

Day 10–15: complete report and corrective plan

Objective: provide authorities with decision-grade information.

Final reporting package should include:

incident chronology
causal analysis and uncertainty boundaries
corrective and preventive actions (CAPA)
deployment restrictions or temporary suspension decisions
monitoring commitments and review cadence

Think of this not as a one-off filing, but as the first artifact in your post-market compliance trail.

Provider–deployer split: define it before incident day

Many AI products involve one company as provider and another as deployer. Under pressure, this becomes a bottleneck unless contracts are explicit.

Minimum contractual clauses to include now:

who files Article 73 notification
max handoff time for incident facts (for example, 24 hours)
evidence retention responsibilities
contact points for regulatory follow-up
authority for emergency suspension / kill switch decisions

Without these clauses, your legal position may be clear on paper but unworkable in operations.

The evidence package regulators usually expect

No two investigations are identical, but teams should prepare to produce:

versioned model and release history
validation/testing evidence relevant to failure mode
human oversight procedures and operator logs
incident triage records and decision timestamps
corrective-action verification data

If you cannot reconstruct what happened from your own records, authorities will assume your controls are weaker than your policy documents claim.

Practical controls that reduce reporting risk

You do not need a huge compliance program to improve immediately. Start with these controls:

AI-specific incident rubric integrated into existing security/ops workflows.
72-hour internal escalation SLA from first signal to legal/compliance review.
Evidence lock protocol for logs, prompts, and model artifacts.
Pre-mapped authority list by country and product footprint.
Quarterly tabletop exercise for one realistic serious-incident scenario.

These five controls usually deliver a larger risk reduction than producing another policy PDF.

What to do this week (if you are behind)

Name your incident lead and backup.
Create a one-page Article 73 trigger matrix.
Test evidence preservation on one live model.
Review provider/deployer language in top customer contracts.
Run one 60-minute simulation with legal + engineering + support.

If these actions feel basic, that is the point. Basic execution under time pressure is what prevents deadline failure.

A sober note on enforcement reality

The AI Act is often discussed as future-state compliance. Incident reporting is different: it is measured against actual operational behavior during real harm events.

Teams that perform well are not the ones with the longest policies. They are the ones with clear ownership, preserved evidence, and repeatable cross-functional response.

If you are already preparing for conformity assessment and post-market monitoring, this playbook should be part of that same system, not a separate legal checklist.

If you want a structured way to track incident-readiness controls and documentation gaps, you can use AktAI’s dashboard:

Related guides:

EU AI Act Conformity Assessment: A Practical Guide for High-Risk AI Providers

Oleksandr Usenko — Sun, 22 Feb 2026 16:33:05 +0000

The Obligation Nobody Talks About Enough

Ask most businesses about EU AI Act compliance and they mention risk classification, technical documentation, and transparency requirements. Far fewer mention the step that legally gates everything else: the conformity assessment.

Under Article 43, providers of high-risk AI systems cannot legally place their systems on the EU market — or put them into service — without completing a conformity assessment first. It is not something you do after launch. It is not a checkbox you add to your release checklist. It is a prerequisite, and as of August 2, 2026, it is enforceable.

This guide explains what a conformity assessment actually involves, what it produces, when you need a third party and when you can self-assess, and where most organizations are getting it wrong.

First: Are You a Provider?

Before worrying about conformity assessment procedures, confirm that you are actually a provider in the legal sense.

The EU AI Act defines providers as entities that develop an AI system and place it on the market or put it into service under their own name or trademark. If you build an AI-powered product and sell it, license it, or deploy it commercially, you are almost certainly a provider. The same applies if you significantly modify an AI system from another source — you may inherit the provider's obligations.

Deployers — organizations that use AI systems built by others — have a different, narrower set of obligations. They must perform fundamental rights impact assessments for certain use cases, maintain human oversight, register in some circumstances, and cooperate with providers. But the heavy conformity machinery falls primarily on the provider.

If you are a business deploying a third-party AI product (say, an HR vendor's recruitment screening tool), make sure your vendor has completed the conformity assessment. Request a copy of their EU declaration of conformity. If they cannot provide one, treat that as a significant red flag — they are placing a non-compliant system in front of you.

What the Conformity Assessment Is Actually For

The conformity assessment is the formal mechanism by which a provider demonstrates that their high-risk AI system meets all the requirements of Chapter III, Section 2 of the AI Act. This includes:

Article 9: A risk management system covering the full AI lifecycle
Article 10: Data governance requirements for training, validation, and testing datasets
Article 11: Technical documentation that would allow an authority to reconstruct and assess the system
Article 12: Logging and record-keeping capabilities built into the system
Article 13: Transparency and information provision to deployers
Article 14: Human oversight mechanisms designed into the system
Article 15: Accuracy, robustness, and cybersecurity requirements

Meeting these requirements is one thing. The conformity assessment is how you prove you meet them — with documentation, testing records, and a formal declaration.

Two Paths: Self-Assessment vs. Third-Party

The AI Act provides two routes to conformity assessment, and which one you must take depends on what type of high-risk AI system you have.

Internal Control (Annex VI) — Self-Assessment

For most high-risk AI systems, providers can conduct an internal conformity assessment following the procedure in Annex VI. This is self-assessment — no notified body involvement required. You build and document the evidence yourself, then sign a declaration of conformity.

Do not mistake "self-assessment" for "informal assessment." Annex VI requires you to:

Document that your quality management system meets Article 17 requirements
Apply relevant harmonized standards (or demonstrate equivalent compliance without them)
Review and update technical documentation in line with Article 11
Maintain internal audit procedures and records
Sign and store the EU declaration of conformity

The self-assessment path is rigorous. Regulators can request access to everything you produced during the assessment process. If you signed a declaration of conformity without the substance to back it up, that is the kind of thing that triggers the heaviest enforcement attention.

Third-Party Assessment (Annex VII) — Notified Body Involvement

For a narrower category of high-risk AI systems — specifically, those that are safety components of products covered by other EU harmonized legislation (like medical devices or machinery), and where no harmonized standards exist that cover the AI-specific aspects — a third-party assessment by a notified body is required.

Notified bodies are accredited organizations designated by member states to assess conformity. They charge fees (often substantial), operate on their own timelines, and are in limited supply. If you fall into this category and have not already engaged a notified body, your August 2026 window is tight.

Check the NANDO database (the European Commission's official notified body database) to find accredited bodies for your product category. Do this now — lead times can be months.

The Conformity Assessment Process in Practice

Regardless of which route applies, the practical work looks similar. Here is a realistic breakdown of the steps involved.

Step 1: Determine High-Risk Classification (If Not Already Done)

Before you can assess conformity, you need to confirm your system is actually high-risk. Article 6 and Annex III define the categories. Common high-risk domains include:

Biometric identification
Critical infrastructure management
Education and vocational training
Employment and worker management
Access to essential private and public services
Law enforcement
Migration and asylum
Administration of justice

If your system falls into one of these categories and makes decisions, assists in decisions, or influences decisions affecting individuals, you are very likely in high-risk territory. The EU AI Act compliance checker can help you work through the classification logic.

Do not assume you are not high-risk just because you are a small company or because your system is not the "main" decision-maker. The Act explicitly covers systems that assist or influence decisions, not just fully autonomous ones.

Step 2: Establish (or Audit) Your Quality Management System

Article 17 requires providers to implement a quality management system (QMS) that covers the entire AI system lifecycle. This is not an optional governance nicety — it is a formal requirement that feeds directly into the conformity assessment.

Your QMS must cover at minimum:

A strategy for regulatory compliance, including how you identify and apply harmonized standards
Procedures for design, development, and design change review
Procedures for technical documentation management
Procedures for post-market monitoring (Article 72)
Procedures for handling serious incidents and reporting to authorities
Data management procedures (feeding into Article 10 compliance)
How you ensure human oversight is implemented (feeding into Article 14)
How you manage third-party AI component suppliers

If you already have an ISO 9001-certified QMS, that is a starting point, not a finish line. The AI Act QMS requirements go further into AI-specific obligations that most existing QMS frameworks do not cover.

Step 3: Build the Technical Documentation

Article 11 and Annex IV define what technical documentation must contain. This is the most documentation-intensive part of the conformity assessment, and the most commonly underestimated.

Required documentation includes:

General description: What the system does, its intended purpose, deployment context, and the persons or groups it is intended to be used for or by
System design and architecture: Functional description, key design choices, system components including software and hardware, the computational graph and input/output specifications
Training methodology: Training data, preprocessing steps, labeling approach, data validation, test and validation procedures
Performance metrics: Accuracy, robustness, and any output limitations — measured across relevant subpopulations and deployment conditions
Risk management documentation: The full record of your Article 9 risk management process — identified risks, risk estimates, mitigations adopted, residual risks accepted
Changes log: A complete record of changes made to the system during development and after deployment
Standards applied: List of harmonized standards or common specifications applied, and how compliance was demonstrated
Human oversight description: How the system provides for operator oversight and intervention, including what override mechanisms exist and how operators are trained

This documentation needs to be maintained for the full lifecycle of the system plus ten years after it is placed on the market. Build systems for maintaining it from the start — retrofitting documentation years later is painful and produces worse outputs.

Step 4: Conduct and Document Testing

Your conformity assessment is not credible without empirical evidence from testing. The AI Act requires testing against intended purpose and foreseeable use — including foreseeable misuse — across the relevant population groups.

Critical testing requirements:

Dataset validation: You must be able to demonstrate that training, validation, and test datasets are relevant, representative, free of errors to the extent possible, and have appropriate statistical properties for the intended purpose
Bias and fairness testing: For systems that affect individuals, you must test for bias across protected characteristics and document results — including where bias remains after mitigation
Robustness testing: Testing for behavior under edge cases, adversarial inputs, and operational stresses
Human oversight validation: Demonstrating that human override mechanisms work as intended under realistic conditions

Keep raw test results, methodology documentation, and test dataset descriptions. These are exactly what a market surveillance authority will request if they investigate.

Step 5: Sign the EU Declaration of Conformity

Once the assessment is complete, the provider must draw up an EU declaration of conformity in accordance with Article 47. This is a legally binding document declaring that the system meets all applicable requirements of the AI Act.

The declaration must be kept for ten years and must be updated when the system is substantially modified (which may trigger a new conformity assessment).

Do not sign this document until the underlying assessment work is actually complete. Signing a declaration of conformity for a system that has not undergone proper assessment is a straightforward path to enforcement action.

Step 6: Affix CE Marking and Register in the EU Database

Article 48 requires high-risk AI systems to bear CE marking (confirming conformity with the Act and any other applicable EU legislation). Article 49 requires providers to register their systems in the EU database before placing them on the market.

The EU database is maintained by the Commission and will be publicly accessible. Registration requires providing summary information about the system, its purpose, risk category, and the provider. This creates an accountability trail — registration means you are publicly on record as a provider of a high-risk AI system.

The Substantial Modification Problem

One area where organizations frequently get caught out is the substantial modification trigger. If you make significant changes to a high-risk AI system after placing it on the market, the AI Act may require you to repeat the conformity assessment for the modified system.

The Act does not define "substantial modification" with mathematical precision — it is a judgment call based on whether the change affects the system's compliance with Chapter III requirements. Relevant factors include:

Changes to the intended purpose
Changes to training data or training methodology
Significant changes to model architecture or components
Changes that affect the system's accuracy, robustness, or the way human oversight functions
Changes that affect the risk profile identified during the original assessment

The practical implication: if you have a high-risk AI system in production and you deploy a significant model update, you need a process to evaluate whether that update triggers a new conformity assessment. Build this into your change management and release processes, not as an afterthought.

What Good Looks Like vs. What We Actually See

Based on what practitioners are encountering across organizations preparing for August 2026, here is an honest picture of where businesses stand.

What good looks like:

Technical documentation is living documentation, maintained as part of the development workflow, not generated retroactively
Risk management is integrated into sprint cycles and release gates, not a separate annual exercise
Testing evidence is version-controlled alongside the model itself
Post-market monitoring is automated where possible, with clear escalation paths for anomalies
The declaration of conformity is reviewed by both legal and technical staff before signing

What we actually see in most organizations:

Technical documentation attempted retroactively, with significant gaps where development decisions were not recorded at the time
Risk management treated as a document rather than a process — a risk register that was filled in once and never updated
Testing limited to standard ML metrics (accuracy, F1 score) without the regulatory-specific testing for bias, robustness, and foreseeable misuse
No process for evaluating whether model updates trigger a new conformity assessment
Legal staff drafting declarations of conformity without full visibility into the underlying technical evidence

Where to Start If You Are Behind

If your conformity assessment work has not started or is materially incomplete, here is the prioritized sequence:

Confirm your risk classification — You cannot plan a conformity assessment without knowing which procedure applies and what Annex III categories are in scope.
Inventory your AI systems — Most organizations do not have a complete picture of all AI systems they operate. The AI systems inventory guide covers how to build one.
Gap-assess your technical documentation — What do you have versus what Article 11 requires? Be ruthless. "We could reconstruct this from our commit history" is not the same as documentation.
Establish your QMS structure — Even if you do not have a formal QMS, document your current process and map it against Article 17. Identify the gaps.
Plan and execute testing — Prioritize bias and robustness testing if you have not done it. These are the areas most likely to require rework if gaps are found.
Engage legal counsel to review draft declarations — Do not treat the declaration of conformity as a boilerplate document. Have qualified legal counsel familiar with the AI Act review it.

If you want a structured way to track progress across all these dimensions, AktAI's compliance dashboard maps your documentation and assessment status against the Article 11 and Article 9 requirements, so you can see gaps without manually cross-referencing regulatory text.

The Timeline Pressure Is Real

August 2, 2026 is approximately five months away. A conformity assessment for a complex high-risk AI system — done properly — takes two to four months of sustained effort for an organization that is reasonably well-prepared. Organizations that are starting from scratch are looking at a compressed, intensive process.

The risk of cutting corners is not abstract. Market surveillance authorities have been explicit that they will request technical documentation and assessment records as part of enforcement investigations. A declaration of conformity unsupported by real assessment work is a liability, not a shield.

Start the assessment process now. Document everything as you go. And if you identify gaps in your high-risk AI system that cannot be remediated in time, have an honest conversation about whether you can continue operating that system after August — or whether you need to temporarily suspend it until compliance is achieved. That is a difficult business decision, but it is a better outcome than enforcement action.

Further reading: The EU AI Act deadlines timeline shows all key compliance milestones. The AI risk assessment guide covers the Article 9 risk management system in depth. The compliance documentation best practices guide addresses technical documentation structure and maintenance.

EU AI Act: What Every Small Business Owner Needs to Know in 2026

Oleksandr Usenko — Sun, 22 Feb 2026 16:25:07 +0000

What Is the EU AI Act?

The EU AI Act is the world's first comprehensive law regulating artificial intelligence. Adopted by the European Union in 2024, it sets rules for how AI systems can be developed, sold, and used across Europe. Think of it as the AI equivalent of GDPR — but instead of protecting personal data, it governs how businesses use AI tools.

If your company operates in the EU and uses any AI-powered tool — from a chatbot to an HR screening system — this law applies to you.

Does It Affect My Small Business?

Yes, almost certainly. The EU AI Act does not only target Big Tech. It applies to any organization that develops, deploys, or uses AI systems within the EU. That includes:

Businesses using AI-powered recruitment tools
Companies using chatbots for customer service
Any organization using AI for decision-making (credit scoring, insurance, etc.)
Businesses using AI content generators, translation tools, or analytics

Even if you only use off-the-shelf AI tools like ChatGPT, Microsoft Copilot, or Grammarly, you still have obligations — particularly around AI literacy (Article 4).

What Are the Key Dates?

The law is being enforced in phases:

February 2, 2025 — Prohibited AI practices banned; AI literacy obligation takes effect (Article 4)
August 2, 2025 — Rules for general-purpose AI models (like GPT, Gemini)
August 2, 2026 — Full enforcement for high-risk AI systems. This is the big deadline.
August 2, 2027 — Existing AI products embedded in regulated goods must also comply

The Article 4 AI literacy deadline has already passed. If you have not addressed it, you are technically non-compliant today.

What Happens if I Don't Comply?

Fines are significant and scaled to company size:

Up to EUR 35 million or 7% of global turnover for using prohibited AI
Up to EUR 15 million or 3% of global turnover for violating high-risk rules
Up to EUR 7.5 million or 1.5% of global turnover for providing incorrect information

For SMEs, the lesser of the absolute amount or turnover percentage applies — but even the lower end is serious for a small business.

What Should I Do Right Now?

Here is a practical four-step plan:

Inventory your AI tools — List every AI-powered tool your organization uses. Include everything from email spam filters to AI recruitment platforms. Our free discovery wizard can help.
Classify the risk — The EU AI Act uses a four-tier risk system: unacceptable, high, limited, and minimal. Your obligations depend on which tier your tools fall into. Use our free risk classifier to check.
Train your staff — Article 4 AI literacy is already mandatory. Every employee who interacts with AI needs to understand the basics. This does not need to be a PhD-level course — proportionate, practical training is what the law requires.
Document everything — Start building records of what AI you use, why, and what safeguards are in place. This documentation is critical for high-risk systems.

How Can AktAI Help?

AktAI automates the entire compliance workflow: AI system classification, document generation, staff training records, and gap analysis. Instead of hiring a consultant for thousands of euros, you can start at EUR 49/month.

Ready to see where you stand? Take our free readiness assessment — it takes less than 2 minutes and requires no signup.