EU AI Act Compliance Checklist for Software Development Teams

The EU AI Act is now enforced. August 2, 2026 activated the main high-risk AI system requirements under Articles 6 through 15, including conformity assessments, technical documentation, human oversight mechanisms, accuracy and robustness standards, and active national enforcement powers. The prohibited AI practices that had been enforceable since February 2025 are now accompanied by the full compliance weight of the regulation's most demanding provisions.

The penalties are not hypothetical. Fines for high-risk system breaches reach 15 million euros or 3 percent of global annual turnover, whichever is higher. For the most serious violations, including prohibited AI practices, the ceiling rises to 35 million euros or 7 percent of global turnover. These figures apply regardless of where your organization is headquartered. If your AI system is deployed to EU residents or used by organizations operating in the EU, the regulation applies to you.

The harder news for software development teams is that the EU AI Act is not a one-time audit. Compliance is continuous. Every significant modification to an AI system can trigger a new conformity obligation. Post-market monitoring is required after deployment, not just before it. And the regulation sits alongside, not instead of, existing frameworks: NIS2, DORA, GDPR, ISO 27001, and sector-specific regulations in healthcare, financial services, and manufacturing all continue to apply to the same systems.

This article gives software development teams the practical checklist they need: what the regulation requires, which teams own which obligations, and how to build compliance into the development process rather than onto it after the fact.

Marka's engineering team works with enterprises across healthcare, manufacturing, finance, and public administration on AI system architecture, governance design, and compliance-ready delivery. If your organization is working through EU AI Act readiness now, reach the team at marka-development.com/contacts.

Step 1: Understand Your Role Under the Regulation

The EU AI Act assigns obligations based on your role in the AI supply chain. Most organizations play more than one role, and the obligations differ significantly between them.

Provider means you develop an AI system and place it on the market or put it into service. This is the highest-obligation role. Providers of high-risk AI systems must complete conformity assessments, maintain technical documentation, register systems in the EU AI systems database, implement quality management systems, and carry out post-market monitoring. If your organization builds AI products that other organizations use, you are a provider.

Deployer means you use an AI system developed by someone else for your own professional purposes. Most enterprises are deployers, even when they use AI tools from third-party vendors. Deployers have their own set of obligations, separate from and in addition to those of providers, including conducting fundamental rights impact assessments for certain high-risk applications, implementing human oversight measures, ensuring staff have adequate AI literacy, and monitoring systems for performance degradation post-deployment.

Importer and distributor roles carry lighter but still real obligations around ensuring providers have completed conformity assessments and that systems bear the required CE marking where applicable.

The first compliance action is documenting which role your organization plays for each AI system in your portfolio. Organizations that have not done this are often surprised to discover they hold provider obligations for internal AI tools they built and deployed for employees, in addition to deployer obligations for the vendor AI tools they use.

Step 2: Classify Every AI System by Risk Tier

The EU AI Act classifies AI systems into four risk tiers: prohibited, high-risk, limited-risk, and minimal-risk. The tier determines what is required, and getting the classification wrong in either direction is expensive: under-classifying a high-risk system produces regulatory exposure, and over-classifying creates unnecessary compliance burden that slows delivery.

Prohibited AI practices have been enforceable since February 2025. If your team has not yet audited against these, that is the most urgent gap. Prohibited practices include AI systems that manipulate persons through subliminal techniques, exploit vulnerabilities of specific groups, implement social scoring by public authorities, perform real-time remote biometric identification in public spaces with narrow exceptions, and infer emotions in workplace or educational settings. If any system in your portfolio touches these areas, legal review is required before another sprint begins.

High-risk AI systems are defined by Annex III of the regulation across eight categories: AI in biometrics, critical infrastructure, education and vocational training, employment and worker management, access to essential private and public services including credit and insurance, law enforcement, migration and asylum management, and administration of justice and democratic processes. Full compliance obligations apply to every system that falls into these categories, including conformity assessment, technical documentation, human oversight, logging, and registration.

Limited-risk systems face transparency obligations only. Chatbots must disclose they are AI. AI-generated content must be labeled. Deepfakes must be disclosed. These obligations are operational rather than architectural, but they require documented processes and evidence of consistent application.

Minimal-risk systems face no mandatory obligations under the regulation. Most productivity tools, spam filters, and basic recommendation engines fall here. The practical action is documenting the classification rationale so you can demonstrate it to an auditor.

The classification exercise needs to be repeated for every third-party AI tool your organization uses, not just systems you build. Extend the same risk classification exercise to all AI-enabled vendors and LLM providers. Your deployer obligations apply regardless of who built the system. Shadow AI, tools that employees use without IT or compliance awareness, is a specific enforcement risk that the classification audit must surface.

Step 3: Complete the Technical Documentation for High-Risk Systems

For high-risk AI systems, technical documentation is not supplementary. It is a mandatory pre-market requirement. Annex IV of the regulation specifies what it must include, and the documentation must be maintained and updated throughout the system's operational life.

The documentation requirement breaks down into specific components that development teams need to build into their delivery processes rather than produce retrospectively.

Architecture decision records. Hardware and software component descriptions, design specifications with the reasoning behind key architectural choices, system architecture documentation, and computational resource requirements are all required under Annex IV. For development teams, this means architecture decision records, which represent good engineering practice regardless of regulation, become compliance documents. ADRs that were previously optional best practice are now mandatory compliance artifacts for any system classified as high-risk.

Training data documentation. Article 10 of the regulation requires detailed documentation of training, validation, and test data: characteristics, provenance, collection methodology, data preparation steps, and known limitations. This is the requirement that most commonly surprises development teams, because training data documentation practices in most organizations do not reach the specificity the regulation requires. Data cards, model cards, and dataset provenance records need to be introduced into the development workflow for any system touching the high-risk categories.

Model performance documentation. Accuracy metrics, robustness testing results, and bias testing must be current and must reflect the model version in production, not the version tested before the last update. This creates a continuous documentation requirement: every time the model is updated, the performance documentation must be updated to match.

Risk management documentation. Article 9 requires a documented risk management system covering identified risks, assessment methodology, mitigation measures implemented, and residual risk accepted. The risk management system is not a document produced once before deployment. It is a living process that runs throughout the system's lifecycle, including post-deployment monitoring.

Conformity assessment. High-risk AI systems must undergo a conformity assessment before being placed on the market. For most Annex III systems, this is a self-assessment against the regulation's requirements, documented in the technical file. For AI systems embedded in regulated products already subject to CE marking, the conformity assessment is conducted by a notified body. The output is the technical file and, where applicable, the CE declaration of conformity.

Step 4: Implement Human Oversight as an Architectural Requirement

Article 14 of the AI Act establishes human agency and oversight as a cornerstone of the regulation. It requires that AI systems be designed and implemented so that they operate under meaningful human control, and that ultimate responsibility remains with human operators. In practice, this means that individuals supervising the system must understand its capabilities and limitations, be able to intervene when necessary, and override its decisions to prevent or mitigate risks.

Human oversight is an architectural requirement, not an operational one. A system that does not have human oversight designed into its architecture cannot demonstrate Article 14 compliance by adding a review step to the deployment checklist. The oversight mechanism must be built into the system itself.

The specific implementation requirements that Article 14 imposes on development teams are the following.

The system must be capable of being monitored by a natural person. This means the system must expose its decision-making in a form that a non-technical supervisor can understand and evaluate. Black-box outputs with no interpretability layer do not satisfy this requirement for high-risk applications.

The system must be capable of being stopped by a natural person. A kill switch or intervention mechanism must be implemented that allows a human operator to halt the system's operation or override a specific output. This is an engineering requirement, not a policy requirement. The mechanism must exist in the code and must be documented in the technical file.

The system must disclose when a human review is required. High-risk systems must be designed to identify cases where their confidence is insufficient, where the decision stakes are high, or where the context is outside their training distribution, and flag those cases for human review rather than proceeding autonomously.

For organizations using LangGraph or equivalent orchestration frameworks, the human-in-the-loop primitive is the implementation mechanism for Article 14 compliance. The interrupt mechanism that pauses agent execution, saves state, and waits for human approval before proceeding is not just a production reliability feature. It is the technical implementation of an EU AI Act requirement for any high-risk agentic system.

Step 5: Establish Logging and Audit Trail Infrastructure

Articles 12 and 13 of the regulation require that high-risk AI systems be designed to automatically generate logs of their operation, with sufficient detail to enable post-hoc accountability for decisions the system made. The logs must be retained for periods appropriate to the system's intended use and must be accessible to national supervisory authorities on request.

The logging requirement is more demanding than it initially appears. Standard application logs record what the system did. The EU AI Act requires logs that enable reconstruction of why the system made a specific decision in a specific context. For AI systems, this means logging the input data, the model version, the inference parameters, the output, the confidence score, and any human oversight action taken in response.

For development teams, this creates three specific implementation requirements.

Immutable log storage. Logs must not be modifiable after the fact. Any system that logs AI decisions to a mutable store, where records could be altered or deleted, does not satisfy the regulation's accountability requirements. Append-only log storage, implemented in Azure Monitor Logs, AWS CloudTrail, or equivalent, with access controls that prevent modification, is the architectural requirement.

Model versioning linked to decision logs. Every decision log must reference the specific model version that produced it. When a model is updated, the version change must be logged and all subsequent decisions must reference the new version. This allows retrospective analysis of whether a specific model version was responsible for a pattern of decisions that are later challenged.

Retention policy aligned to regulatory requirements. The regulation does not specify a universal retention period. It requires retention appropriate to the system's intended use. For high-risk systems in regulated industries, the appropriate retention period is typically determined by the sector-specific regulation that also applies: HIPAA for healthcare, MiFID II for financial services, and similar. The retention policy must be documented and enforced technically, not just stated in policy.

Step 6: Build the Quality Management System

Article 17 requires providers of high-risk AI systems to implement a quality management system covering regulatory compliance strategy, system design techniques and procedures, development procedures, test and validation processes, technical specifications, data management procedures under Article 10, the risk management system under Article 9, the post-market monitoring system, serious incident reporting procedures, communication procedures with deployers, and document management ensuring traceability throughout the lifecycle.

Mature engineering organizations will find that much of this content already exists in their development processes. The gap is usually in formalisation, documentation, and explicit linkage to AI governance requirements rather than in the underlying practices themselves.

The practical action for development teams is to audit existing processes against the QMS requirements and produce the documentation that maps existing practices to regulatory obligations. An SDLC that already includes documented testing procedures, version control, code review processes, and change management documentation is most of the way to a compliant QMS. The remaining work is typically formalizing the AI-specific additions: training data governance, model evaluation criteria, and the human oversight mechanisms that standard software QMS documents do not address.

For organizations seeking a certifiable framework, ISO 42001, the international standard for AI management systems, provides a structure that satisfies the EU AI Act's QMS requirements and is increasingly recognized by national enforcement authorities as evidence of systematic compliance. ISO 42001 aligns with ISO 27001's structure, making joint implementation feasible for organizations already certified on the information security standard.

Step 7: Register High-Risk Systems in the EU AI Database

Providers of high-risk AI systems must register them in the EU AI systems public database before placing them on the market. Deployers of high-risk AI systems used in public administration must also register their use. The database is managed by the European AI Office.

The registration requirement has a practical implication that development teams frequently miss: the registration must occur before deployment, not after. A high-risk AI system that goes live without registration is in breach of the regulation from the moment of deployment, regardless of whether the system itself is technically compliant with Articles 9 through 15.

Registration information includes a description of the system's intended purpose, the categories of data processed, the accuracy and robustness metrics declared, the human oversight measures implemented, and the contact information for the provider. This information must be kept current: if the system's intended purpose changes materially, a new registration is required.

Step 8: Implement Post-Market Monitoring

The EU AI Act does not have a finish line. The regulation requires continuous monitoring after market entry. If a system's accuracy degrades over time, this must be detected, reported, and corrected. Ongoing risk assessments are required throughout the operational lifecycle, not just before deployment.

Post-market monitoring for AI systems requires three capabilities that standard software monitoring does not typically include.

Model performance drift detection. AI model performance degrades when the real-world data distribution diverges from the training data distribution. A model that performed accurately at launch may produce biased or unreliable outputs twelve months later as the underlying reality it was trained on changes. Monitoring must detect this drift and trigger model review and retraining as required.

Bias and fairness monitoring. High-risk AI systems must not produce discriminatory outputs. Post-market monitoring must include ongoing evaluation of the system's outputs across demographic groups, with documented evidence that bias controls are operating as intended.

Serious incident reporting. Article 73 of the regulation requires providers to report serious incidents to national market surveillance authorities. A serious incident is one that results in death or serious harm to health, a significant disruption to critical infrastructure, a breach of fundamental rights, or serious damage to property or the environment. The reporting timeline is thirty days for incidents that are serious but not life-threatening, and fifteen days for life-threatening incidents. Development teams need documented incident response procedures that specifically address this reporting obligation before deployment, not after the first incident.

The Compliance Architecture That Development Teams Should Build

The most expensive mistake in EU AI Act compliance is treating it as a legal and documentation exercise rather than an architectural one. Organizations that embed EU AI Act requirements from the architecture phase reduce post-deployment governance costs by 58% compared to those that retrofit compliance controls after development. The controls that Articles 9 through 15 require, human oversight mechanisms, immutable audit logs, model versioning, performance monitoring, and risk management documentation, are significantly cheaper to build correctly in the first sprint than to add to a system that was not designed for them.

The practical architecture for compliance-by-design includes the following components.

A governance layer at the orchestration level that enforces human oversight rules, captures audit-ready decision logs, and manages the intervention mechanisms required by Article 14. For teams using Azure as the deployment platform, Azure AI Foundry provides this layer with EU AI Act compliance tooling built in. For teams using LangGraph, the interrupt mechanism and state persistence layer are the implementation foundation.

A data governance pipeline that tracks training data provenance, maintains model versioning linked to deployment events, and preserves the documentation required by Article 10 and Annex IV in a form that survives model updates.

A monitoring stack that detects model performance drift, evaluates fairness metrics continuously, and feeds the post-market monitoring obligations under Article 72. Azure Monitor, combined with custom fairness evaluation pipelines, provides this capability for Microsoft-stack organizations.

An incident response procedure that specifically addresses Article 73 reporting timelines and the escalation path from a detected serious incident to a national authority notification.

Marka's Cloud and Platform Modernization practice builds these components into AI system architecture from the start of each engagement, because the cost of building compliance in is consistently lower than the cost of retrofitting it and significantly lower than the cost of an enforcement action. As a Microsoft Gold Certified Partner, the team's Azure-native implementation of compliance architecture covers the technical documentation, audit logging, human oversight, and post-market monitoring requirements that the regulation imposes, within the infrastructure that most enterprise clients are already running.

What to Do Next

Three actions are worth taking before the next sprint cycle regardless of where your organization currently sits on EU AI Act readiness.

Run the AI system inventory and risk classification. Every AI system your organization builds or uses needs a documented risk tier and a documented role classification. This is the foundation of every other compliance action. Organizations that have not completed this step do not know their compliance exposure, which is itself a governance failure that enforcement authorities have explicitly identified as an indicator of non-compliance.

Audit your technical documentation against Annex IV. For every system you have already classified as high-risk, compare your existing documentation against the Annex IV requirements. Architecture decision records, training data documentation, performance metrics, and risk management documentation are the most common gaps. Each gap is a specific documentation task with a specific owner.

Map your incident response procedures to Article 73 timelines. The fifteen and thirty-day reporting timelines in the regulation are shorter than most organizations' existing incident response cycles. If your incident response procedures do not specifically address AI system serious incidents with EU AI Act reporting obligations, that gap needs to close before the next deployment.

For organizations that need engineering support implementing the technical architecture that compliant AI systems require, Marka's team works across healthcare, manufacturing, finance, and public administration on exactly this work. You can review the full scope of Enterprise Platforms and Modernization work the team delivers or reach out directly at marka-development.com/contacts.