Tech & AIInsightsAboutCareers Book a call

Blog Article

EU AI Act Compliance Is an Engineering Problem

Why European technology leaders have to close the gap between claiming EU AI Act compliance and actually demonstrating it in production.

Author

Incresco

Incresco

AI & Product Strategy Team

December 2, 2027 is the key new application date for high-risk AI systems under Article 6(2) and Annex III. The Digital Omnibus on AI postponed the original August 2026 application date. Whether systems already in use fall within those requirements from that date also depends on the transition rules in Article 111. The gap between claiming compliance and being able to demonstrate it has therefore acquired immediate regulatory significance.


The most important point is this: the organizations most exposed are not only those that ignored the regulation. Organizations that treated EU AI Act compliance exclusively as a legal issue and assigned the technical implementation to the wrong team are also at risk.


The Numbers and Compliance Gaps Every CTO Should Know


88% of respondents report that their organizations use AI in at least one business function, according to McKinsey.


Without a systematic inventory of AI systems in production and development, an organization cannot reliably determine its regulatory scope, roles, or obligations.


A 2023 appliedAI study could not unambiguously classify 40% of 106 use cases. The study examined an earlier draft of the regulation and therefore does not measure current compliance maturity. It does, however, show how demanding a defensible classification can be.


Taken together, the picture is clear. AI use is widespread, while inventory and risk classification require dedicated technical and organizational work. At the same time, European companies must operationalize a regulation whose staggered application dates are now fixed.


The penalty structure also makes this a board-level issue. Breaches of deployer obligations under Article 26, or of the other duties enumerated in Article 99(4), can lead to administrative fines of up to €15 million or, where the offender is an undertaking, up to 3% of its total worldwide annual turnover for the preceding financial year, whichever is higher. Supplying incorrect, incomplete, or misleading information in the circumstances covered by Article 99(5) carries a separate maximum of €7.5 million or, for an undertaking, 1% of total worldwide annual turnover. Prohibited AI practices under Article 5 carry a maximum of €35 million or, for an undertaking, 7% of total worldwide annual turnover. For SMEs, the lower amount applies in each case; for fines under Article 99(4) and (5), the Digital Omnibus extends that rule to small mid-cap enterprises as well.


But the fine is not the real risk. The larger problem often becomes visible only during the compliance work: the technical infrastructure needed to demonstrate compliance was never built.


EU Artificial Intelligence Act


Why EU AI Act Compliance Often Sits With the Wrong Function


Ask a European enterprise today who owns EU AI Act compliance. The answer is usually the legal team, supported by the compliance function.


That does not go far enough.


In 2026, EU AI Act compliance is first and foremost a product development, engineering, and procurement task. The concrete work includes logging infrastructure for audit-ready evidence, technically effective human-oversight mechanisms, and compliance gates in development and deployment workflows.


None of that is created by a policy document alone. A legal memorandum does not deliver technical implementation. The work requires engineering, and many organizations have not yet started it.


The legal team can explain the requirements that the regulation places on providers and deployers. It does not build the logging capability that a high-risk AI system must technically support. The compliance team can define expectations for human oversight, but it does not necessarily design the architecture that makes that oversight effective in operation. The CTO, VP of Engineering, and engineering teams can do precisely that.


This discussion belongs on the technology leadership agenda.


What Is the EU AI Act?


The EU AI Act is the first comprehensive legal framework for artificial intelligence. Adopted in 2024, it entered into force on August 1, 2024 and establishes binding rules for the development, placing on the market, deployment, and use of AI systems in the European Union.


Its scope can also include organizations outside the EU. This applies, among other cases, when providers place AI systems on the EU market or put them into service in the EU, or when output produced by a system is used in the EU. A company in London, Singapore, or New York may therefore fall within scope if its AI solution is used for decisions in Germany or France. The location of the company alone is not decisive; the specific placing on the market, putting into service, and use matter.


The regulation follows a central principle: the greater the risk an AI system poses to health, safety, or fundamental rights, the stricter the requirements. This creates the risk-based framework that determines the applicable obligations.


As a simplification, the regulation can be thought of as a kind of “GDPR for AI,” although its operational reach is different. While the GDPR governs the processing of personal data, the EU AI Act addresses specified AI systems and practices that can affect people’s lives. These include decisions about employment, access to credit, educational assessment, and law enforcement.


Several application phases have already begun. Prohibitions on certain AI practices and provisions on AI literacy have applied since February 2025. Governance rules and obligations for providers of general-purpose AI models have applied since August 2025. Further provisions, including the transparency obligations in Article 50, apply from August 2026. The central requirements for high-risk AI systems under Annex III apply from December 2, 2027, while those for product-related high-risk systems under Annex I apply from August 2, 2028.


Unlike a directive, which each Member State must transpose into national law, an EU regulation applies directly. Its obligations therefore apply, as a general rule, at the same time in Berlin, Amsterdam, Paris, Stockholm, and Warsaw.


National competent authorities and the European AI Office are progressively building their supervisory and enforcement structures. Enforcement is no longer an abstract future issue, even though some obligations apply only at later dates.


The EU AI Act does not replace the GDPR; it applies alongside it. If a high-risk AI system processes personal data, both frameworks may be relevant. Article 27 of the AI Act requires a fundamental rights impact assessment for specified deployers and use cases. Where its conditions are met, Article 35 of the GDPR additionally requires a data protection impact assessment. Coordinating the two processes can avoid duplicated work and inconsistent outcomes.


What the EU AI Act Requires From Engineering


In practice, the framework is often described through four risk tiers. The first technical task is to classify every AI system correctly based on its intended purpose and actual use. The organization must also determine whether it acts as a provider, deployer, or another operator, because its role determines its obligations.


AI practices with unacceptable risk are generally prohibited. Subject to specific conditions, these include social scoring, exploitation of particularly vulnerable groups, and certain forms of real-time remote biometric identification in publicly accessible spaces for law-enforcement purposes. The exact statutory conditions and exceptions matter.


High-risk AI systems under Annex III affect many organizations. They include certain applications in employment and recruitment, creditworthiness assessment, biometrics, critical infrastructure, education, and law enforcement. Not every AI system used in these areas is automatically high-risk. Intended purpose, deployment context, and the classification rules in Article 6 determine the result.


AI systems with limited transparency risk are subject to specific obligations under Article 50. People must generally be informed when they interact directly with an AI system such as a chatbot, unless that interaction is obvious. Providers of generative systems must generally mark synthetic audio, image, video, and text outputs as artificially generated or manipulated in a machine-readable format, subject to statutory technical and content exceptions. Deployers of deepfake systems and systems producing certain text on matters of public interest have separate disclosure duties and exceptions.


AI systems with minimal risk face no specific obligations under the regulation unless another provision applies.


EU AI Act risk tiers — from unacceptable to minimal risk


Classification remains difficult. The 2023 appliedAI study of the draft regulation could not unambiguously classify 40% of the use cases examined. That figure cannot be transferred directly to the regulation now in force, but it illustrates why classification requires a documented rationale rather than assumptions.


Once systems have been classified, the technical duties become concrete. Articles 9 to 15 set requirements for high-risk AI systems and are implemented primarily by their providers. Deployers have separate obligations, particularly under Article 26.


  • Article 9 requires a documented, continuous risk-management system. A one-time assessment is not enough.

  • Article 10 sets requirements for data and data governance, including data provenance, quality criteria, and documentation of testing for potential bias.

  • Article 11 and Annex IV require complete technical documentation covering, among other matters, the intended purpose, design decisions, characteristics of the data used, and performance metrics.

  • Article 12 requires high-risk AI systems to technically enable the automatic recording of relevant events throughout their lifecycle. Articles 19 and 26 separately govern the retention of automatically generated logs by providers and deployers.

  • Articles 13 and 14 govern transparency and information for deployers as well as effective human oversight. That oversight must be technically and organizationally possible in practice.

  • Article 15 requires an appropriate level of accuracy, robustness, and cybersecurity throughout the lifecycle of a high-risk AI system.

  • Article 26 defines deployer obligations. These include use according to the instructions, competent human oversight, monitoring of operation, and retention of automatically generated logs under the deployer’s control for an appropriate period of generally at least six months. Provider documentation alone does not show how a high-risk AI system is used and monitored in the deployer’s own operating environment. Internal evidence, processes, and escalation paths are also required.

The Question Many Compliance Teams Cannot Answer


Ask your compliance team this question today:


“Can we produce internal evidence showing how every high-risk AI system is used within our organization?”


If that question cannot be answered clearly in the affirmative, the reason is not necessarily a lack of care. Organizations have often assumed that provider documentation also covers their own deployer processes. A provider can supply instructions for use, system documentation, and testing information. The deployer additionally needs the internal evidence required for its specific use, monitoring, and oversight.


The largest gap is often the inventory. When organizations are asked to name every AI system in use, they usually identify three or four obvious solutions. Then HR mentions a screening tool in a pilot. Legal identifies a contract-classification system. Finance uses an anomaly-detection model for fraud prevention. Every one of these systems must be inventoried and assessed based on its actual use.


If there is no systematic register of AI systems in production and development, an inventory must come before risk classification. Every AI tool, model, and automated decision system should be catalogued, including third-party solutions and AI capabilities embedded in enterprise software.


This is where compliance often fails: not in the internal policy, but in the missing inventory.


The Underestimated Shadow AI Problem


A second risk sits underneath the formal compliance discussion.


A Harmonic Security industry analysis found that 64.5% of activity in personal AI accounts served business purposes. Unsanctioned tools of this kind often sit outside an organization’s security, privacy, and governance processes.


If an employee uses an unauthorized AI tool for a decision affecting people in the EU, the result may create regulatory risk depending on the system, deployment context, and the organization’s role. Whether specific Annex III obligations apply must be assessed against the actual use case. Internal approval alone does not determine the legal classification.


The compliance perimeter is therefore wider than many organizations initially assume. Governance also becomes a cultural and organizational task, not merely a technical one.


Compliance is a puzzle — every piece must fit


What Demonstrable EU AI Act Compliance Actually Requires


As the next application dates approach, one distinction matters above all: claiming compliance is not the same as demonstrating it.


Claiming compliance: An internal compliance policy exists. The legal team has reviewed it. The compliance team signs off quarterly.


Demonstrating compliance: A competent authority asks how an AI system used for employment decisions operates, how relevant events are logged, who exercises oversight, and what happens when it produces an anomalous result. Your organization can answer with current documentation and existing system evidence instead of assembling the record after the fact.


The following five components form a recommended technical control framework. They are not an exhaustive statutory checklist; the precise duties depend on the system’s risk class and the organization’s role.


  1. AI system inventory. Every system in production, development, and procurement is recorded. The review covers scope and role, prohibited practices under Article 5, high-risk classifications under Article 6 together with Annexes I and III, the exception assessment under Article 6(3), transparency obligations under Article 50, and obligations for general-purpose AI models where relevant. The inventory is maintained continuously rather than treated as a one-time audit.

  1. Audit-ready logging infrastructure. Providers must design high-risk AI systems under Article 12 so that relevant events can be recorded automatically and must retain the logs under their control in accordance with Article 19. Under Article 26, deployers retain only the automatically generated logs under their control. Incidental application logs are not a substitute for deliberately designed evidence.

  1. Human-oversight architecture. Under Article 14, providers design high-risk AI systems so that natural persons can oversee them effectively. Under Article 26, deployers assign oversight to people with the necessary competence, training, and authority. This includes defined escalation paths, intervention capabilities, and documented decision authority within the workflow.

  1. Technical documentation under Annex IV. Providers fully document intended purpose, design decisions, characteristics of the data used, performance metrics, and known limitations, and keep that documentation current. Deployers combine the provider documents, operational information, and internal evidence needed to meet their own obligations.

  1. Compliance gates in development workflows. Classification and documentation requirements are integrated into development and deployment. New AI systems do not reach production until the checks applicable to their role and risk class have been completed.

None of this is created by legal review alone. It requires technical decisions, appropriate infrastructure, and clearly assigned engineering ownership. At the same time, this control framework by itself is not sufficient to satisfy every obligation under the regulation or demonstrate complete compliance.


EU AI Act in a Nutshell — key principles at a glance


Note: This image, shared with the German version, still uses the word “proposes.” The EU AI Act is now in force and has been amended by the Digital Omnibus on AI.


The Cost of Waiting


Worldwide spending on AI governance platforms is expected to reach $492 million in 2026 and exceed $1 billion by 2030, according to Gartner. Gartner also projects that effective governance technologies could reduce regulatory compliance costs by 20%.


Depending on the organization’s role and the number and complexity of its systems, compliance programs for high-risk AI can require substantial budgets. When made early and structured correctly, these investments create infrastructure that delivers value beyond the statutory application dates. Documentation, logging, and oversight mechanisms also make AI systems more reliable, auditable, and trustworthy to enterprise customers.


Organizations that treat this exclusively as a compliance burden spend money to satisfy regulatory requirements. Those that treat it as an engineering standard build infrastructure whose value grows with every additional system.


There is also an often-overlooked differentiation advantage. Organizations with controlled, documented, and auditable AI systems improve their chances of winning contracts in regulated industries, succeeding in public-sector procurement, and earning the trust of customers who increasingly care about how AI affects their lives.


The staggered application dates are progressively turning responsible AI practices into legal requirements. Organizations already doing this work can build a genuine competitive advantage over less-prepared competitors.


What Well-Prepared Organizations Are Doing Now


Technology leaders handling this well follow a recurring pattern. The deciding factor is not budget alone, but who owns the problem.


In the best-prepared organizations, the CTO or VP of Engineering directly owns the technical compliance work. It is not delegated to legal with engineering merely providing support. Engineering leads, while legal advises.


The engineering team has created an AI system inventory that extends beyond obvious enterprise systems. It also captures departmental tools, pilot projects, and third-party integrations in SaaS platforms already in use.


The development process includes compliance gates. New AI systems require documented classification before they reach staging. For providers, Annex IV documentation is a delivery requirement rather than a retrospective exercise; deployers embed their own evidence and monitoring obligations into the implementation process.


Logging infrastructure is also built early, not immediately before the relevant application date.


The Incresco Approach to Technical Compliance


Our work with European technology organizations on EU AI Act compliance always starts in the same place.


Not with a policy review. Not with an isolated legal assessment. With an AI system inventory.


We map what is already in production, what is being developed, and which AI capabilities are embedded in third-party systems. We then assess scope and role, Article 5, high-risk classification under Article 6 together with Annexes I and III—including Article 6(3)—Article 50 transparency obligations, and requirements for general-purpose AI models where relevant. We document the rationale and identify gaps in Article 26 deployer obligations, particularly missing internal evidence of use or cases where provider documentation is incorrectly treated as sufficient evidence for the deployer’s own processes.


From there, the engineering work follows a clear sequence: logging infrastructure before documentation routines. Oversight architecture before governance policy. Inventory before everything else.


Our clients have not overlooked the regulation. They recognized early that demonstrable compliance is an engineering problem and want a partner that can build the required infrastructure rather than merely describe it.


If your AI systems are already in production and the Article 6 assessment against Annexes I and III has not begun, now is the time to start.


The Current EU AI Act Timeline


Historical EU AI Act timeline from before the Digital Omnibus on AI


Note: This image, shared with the German version, shows the timeline from before the Digital Omnibus on AI. The updated dates below are the ones that apply.


February 2, 2025: Prohibitions on certain AI practices and the provisions on AI literacy became applicable.


August 2, 2025: Governance rules and obligations for providers of general-purpose AI models became applicable.


August 2, 2026: Further general provisions of the EU AI Act became applicable, including the transparency obligations in Article 50.


December 2, 2026: New prohibitions introduced into Article 5 by the Digital Omnibus on AI become applicable. By this date, providers of systems that generate synthetic content and were placed on the market before August 2, 2026 must also comply with Article 50(2).


December 2, 2027: The requirements and obligations for high-risk AI systems under Article 6(2) and Annex III become applicable.


August 2, 2028: The requirements and obligations for product-related high-risk AI systems under Article 6(1) and Annex I become applicable.


AI systems that are components of the large-scale IT systems listed in Annex X follow the separate transition rule in Article 111(1): if they were placed on the market or put into service before August 2, 2027, they must be brought into compliance by December 31, 2030. For other high-risk AI systems placed on the market or put into service before the relevant Annex III or Annex I application date, Article 111(2) generally applies the later high-risk requirements only if the system’s design is significantly changed after that date; Article 5 remains unaffected. Providers and deployers of high-risk AI systems intended for use by public authorities must in any event take the necessary steps to comply by August 2, 2030.


Technical implementation often takes longer than teams expect. The inventory alone can reveal systems whose classification, documentation, and technical controls require several months of work.


Organizations that start early can demonstrate compliance when the relevant obligations become applicable. Those that wait until the final phase may first have to explain their implementation plan to a competent authority.


Start With One Question


If you take only one idea from this article, make it this one.


Ask your compliance team, CTO, and VP of Engineering to answer one question together this week:


“Can we demonstrate—not merely claim—how every high-risk AI system is currently used within our organization?”


The answer shows where your organization stands.


If the answer is yes, and you can produce the documentation required for your role, the logs under your control, and evidence of structured human oversight, central technical prerequisites are in place. A complete compliance assessment must also address every other applicable obligation.


If the answer is no, or the room goes quiet, you know what needs to happen in the coming months.


Incresco works with engineering teams across Germany, the Netherlands, France, and the Nordics on precisely these tasks. Not isolated internal policies or legal opinions, but the technical infrastructure organizations need to meet EU AI Act requirements with defensible evidence.


If this is a conversation you need to have, we are ready.


Book a 30-minute working session with Incresco



Incresco is a technology consulting firm working with global enterprises on AI engineering, production readiness, and regulatory compliance. This piece was written in May 2026 and updated in August 2026 to reflect the Digital Omnibus on AI.

Ready to stop experimenting and
start operating?