AI compliance is no longer a future concern for European enterprises. It is already shaping how custom software should be planned, designed, developed, documented, and deployed.
The EU AI Act, formally known as Regulation (EU) 2024/1689, introduces a new reality for companies building or using artificial intelligence in the European market. Product owners can no longer treat compliance as something to check right before launch. Engineering teams can no longer build AI systems first and ask legal teams to “make them compliant” later.
The regulation changes the development process itself. It requires businesses to understand what kind of AI system they are building, what risk category it falls into, who is legally responsible for it, what data it uses, how it is monitored, and how human operators remain in control.
For companies investing in custom AI development, this creates a direct technical challenge: compliance must be addressed during architecture, not patched onto the software after release.
This guide explains what Regulation (EU) 2024/1689 covers, how it affects core industries, and how Lionwood Software supports technical compliance through a Compliance-by-Design development methodology.
What Is Regulation (EU) 2024/1689 and What Does It Cover?
Regulation (EU) 2024/1689 is the official legal framework behind the EU AI Act. It is a horizontal, risk-based regulation, which means it does not apply only to one industry or one type of software. Instead, it applies broadly to AI systems placed on the European market or used in the EU, including systems developed by companies outside the EU.
For custom software development, this point is critical. A company does not avoid the AI Act simply because its development team, vendor, or technical partner is located outside the European Union. If the AI system is made available in the EU or affects people in the EU, the regulation may apply.
The Act classifies AI systems according to risk. The higher the potential impact on safety, rights, access to services, employment, healthcare, infrastructure, or public interest, the stricter the obligations.
The Core Risk Classification Framework
Unacceptable Risk: These AI practices are prohibited. This category includes systems that manipulate human behavior in harmful ways, perform social scoring, exploit vulnerable groups, or use certain forms of biometric data collection and identification in banned contexts. For business leaders, the message is clear: these systems should not be built, deployed, or commercialized in the EU market.
High-Risk: These systems are allowed but strictly regulated. High-risk AI may include systems used in critical infrastructure, healthcare, employment, education, law enforcement, migration, access to essential services, or safety-related product functions. These systems require strong technical documentation, data governance, logging, transparency, human oversight, risk management, cybersecurity, and post-market monitoring.
Limited Risk: These systems are generally allowed but must meet transparency obligations. Examples include customer-facing chatbots, AI-generated text or media, certain emotion recognition interfaces, and systems where users must be clearly informed that they are interacting with AI or viewing AI-generated content.
Minimal or No Risk: These systems carry lighter obligations. Examples may include standard business productivity tools, spam filters, simple recommendation engines, or internal support features that do not significantly affect rights, safety, employment, healthcare, or access to essential services.
The key practical issue is that classification depends on the intended use of the system. The same underlying AI model may be minimal-risk in one context and high-risk in another. A prediction engine used for general inventory planning is not the same as an AI system used to make safety-critical decisions in transport infrastructure or clinical workflows.
The Enforceability Timeline
The EU AI Act entered into force on August 1, 2024. Prohibited AI practices became applicable from February 2, 2025. The general application framework continues to settle around August 2026.
However, the EU Digital Omnibus update has changed the high-risk compliance planning horizon. Under the recent adjustments, standalone high-risk AI systems under Annex III are moving toward a December 2, 2027 enforceability target, while product-integrated high-risk systems under Annex I are expected to follow in August 2028.
This does not mean companies can wait. Custom AI products planned today may take months to design, build, validate, secure, document, and deploy. If the system falls into a high-risk category, the architecture decisions made now will directly affect whether the product is ready for the coming compliance deadlines.
Industrial Touchpoints: What the Act Means for Core Verticals
Regulation (EU) 2024/1689 is not abstract for industries that depend on data, automation, and operational decision-making. Its impact becomes clearer when viewed through real business domains where Lionwood Software operates.
Logistics and Supply Chain
AI is increasingly used in logistics to optimize transit routes, forecast delivery times, manage warehouses, automate dispatching, and improve supply chain visibility.
In many cases, these tools may remain outside the strictest compliance categories. However, the risk profile changes when AI becomes connected to critical transportation infrastructure, safety-sensitive routing, or automated dispatch decisions with serious operational consequences.
For example, an AI system that only suggests more efficient internal delivery routes may require transparency, monitoring, and sound data governance. But an AI system that directly controls or influences critical transport infrastructure may move closer to high-risk classification.
From a technical perspective, logistics AI systems should be built with clear data provenance, event logging, route recommendation explainability, manual override options, and monitoring for abnormal output patterns.
Healthcare and Medical Software
Healthcare is one of the clearest high-sensitivity domains under the EU AI Act. AI used in diagnostics assistance, automated patient triage, clinical recommendation workflows, medical imaging support, or patient risk scoring may trigger strict obligations.
The main issue is not whether AI is useful in healthcare. It clearly can be. The issue is whether the system is accurate, explainable, monitored, secure, and properly supervised by qualified human professionals.
A healthcare AI system must not become a black box that quietly influences clinical decisions without traceability. It should be designed with controlled datasets, documented model behavior, human-in-the-loop review, audit logs, and role-based access for clinicians, administrators, and compliance teams.
For custom healthcare software, Compliance-by-Design is not optional. It is the only realistic way to prevent late-stage re-engineering, unclear accountability, and weak audit readiness.
Manufacturing
AI in manufacturing can support predictive maintenance, anomaly detection, industrial quality control, production scheduling, and defect identification.
The compliance risk depends on how the AI system is used. If a predictive maintenance tool helps reduce downtime, the risk may be limited. If the same system influences machinery safety, worker protection, or quality control in a way that could create physical risk, the compliance burden becomes more serious.
Manufacturing AI architecture should therefore include robust monitoring, failure-mode testing, event logging, secure access controls, and clear escalation mechanisms. When AI output may affect workplace safety or product quality, human oversight cannot be vague. It must be built directly into the workflow.
Digital Assets and Blockchain
Blockchain and digital asset systems are not automatically high-risk AI systems. However, they often involve technical requirements that overlap strongly with AI Act expectations: traceability, data integrity, secure identity flows, validation logic, and tamper-resistant records.
This is especially relevant when AI is used to automate provenance checks, validate asset histories, detect fraud, classify digital objects, or support automated decision-making around ownership, authenticity, or lifecycle events.
Lionwood’s experience in blockchain-based systems is valuable here because regulated AI architecture also depends on auditability. When a system must prove what happened, when it happened, who performed an action, and whether records were modified, engineering discipline becomes a compliance asset.
How Lionwood Supports Technical Compliance on Its Part
Lionwood Software does not replace the legal responsibilities of the Provider or Deployer. The final compliance status of an AI product depends on its intended purpose, risk category, market role, documentation, use context, and regulatory assessment.
What Lionwood can do is build the technical foundation required for compliance: architecture, data controls, logging, documentation support, human oversight mechanisms, cybersecurity, and audit-ready system behavior.
That is the practical meaning of Compliance-by-Design in custom AI development.
1. The Discovery Phase as a Compliance Risk Gate
Compliance begins before the first line of code. During the Discovery Phase, Lionwood helps define the system’s intended purpose, user groups, data flows, operational boundaries, and risk exposure.
This early work matters because AI Act obligations depend heavily on context. A chatbot, a logistics optimization system, and a healthcare triage engine cannot be treated as the same type of product.
During Discovery, the team can assess:
Intended Use: What decision or workflow will the AI system support, automate, or influence?
Risk Tier: Is the system likely to be minimal-risk, limited-risk, high-risk, or prohibited?
System Boundaries: Which parts of the product use AI, and which parts remain rule-based, manual, or externally controlled?
Data Flows: What data enters the system, where it comes from, how it is processed, and where it is stored.
Human Control Points: Where human review, approval, override, or escalation must be built into the workflow.
Third-Party Dependencies: Whether the system relies on external AI models, APIs, cloud tools, or data processors.
This process reduces the risk of expensive late-stage changes. Instead of discovering compliance gaps after development, the product team can shape the architecture around the correct regulatory profile from the start.
2. High-Fidelity Data Governance Under Article 10
Article 10 places strong emphasis on data governance for high-risk AI systems. In engineering terms, this means AI systems must be built on data that is controlled, relevant, representative, and suitable for the intended purpose.
Lionwood supports this through structured data governance practices.
Data Lineage Tracking: The architecture should define where training, validation, and testing datasets originate, how they were collected, and how they move through the system.
Dataset Provenance: Each dataset should have a clear source, ownership context, processing history, and intended use.
Relevance Assessment: Data should be checked against the real operational environment where the AI system will be used.
Bias Mitigation Testing: Automated validation flows can help detect missing values, historical bias, anomalies, imbalanced data, or outdated records.
Data Quality Monitoring: The system should not treat data quality as a one-time setup task. Production data must be monitored over time to detect drift, degradation, or unexpected input patterns.
For example, if an AI system supports manufacturing quality control, the model should be trained and tested on data that reflects actual production conditions. If a healthcare AI feature supports clinical workflows, the system must be far more careful about data representativeness, patient safety, and the limits of algorithmic output.
Good data governance is not only a legal requirement. It is also the foundation of useful AI.
3. Traceability, Secure Logging, and the Lingon Parallel Under Articles 11 and 12
Articles 11 and 12 focus on technical documentation and automated record-keeping for high-risk AI systems. From a software engineering point of view, this means the system must be able to explain its operational history.
A compliant architecture should make it possible to understand what happened inside the system: what input was received, what model or configuration was active, what output was generated, which user took action, and whether the event was reviewed, overridden, or escalated.
Lionwood supports this through audit-ready engineering patterns.
Automated System Auditing: AI systems should generate structured logs that capture relevant inputs, outputs, model versions, user actions, and configuration changes.
Secure Log Preservation: For high-risk AI systems, deployers must keep automatically generated logs under their control for at least 6 months under Article 26. The architecture should support this requirement through clear retention policies and secure storage.
Model Configuration Tracking: The system should record which model, prompt version, dataset version, or rule configuration was active at the time of a decision.
Tamper-Resistant Records: Logs should be protected from unauthorized modification, deletion, or silent manipulation.
Incident Investigation Support: If the system behaves unexpectedly, the team should be able to reconstruct the sequence of events without relying on guesswork.
The Lingon Certificates project is a useful proof point for this type of engineering maturity. In that project, Lionwood built a mobile application for generating unique digital certificates and registering ownership of e-commerce assets on the blockchain. The system supported authenticity checks through QR scanning, ownership registration, secure authentication, and certificate lifecycle tracking.
The project was not an AI Act compliance product. Its relevance is architectural. Blockchain-based certificate generation requires secure records, traceable events, and protection against tampering. These are the same engineering principles required for audit-ready AI systems where logs, lifecycle events, and system decisions must remain reliable.
In other words, the Lingon parallel shows that Lionwood has practical experience building systems where traceability is not a feature added later. It is part of the core architecture.
4. Human Oversight and Granular Role Models Under Article 14
Article 14 requires high-risk AI systems to support effective human oversight. In custom software, this must be translated into real interface and workflow design.
A weak implementation would simply add a generic “review required” label. A strong implementation gives qualified people the tools to supervise, question, override, pause, or stop AI operations when needed.
Lionwood supports this through granular role and workflow design.
Human-in-the-Loop Controls: Sensitive AI outputs can be routed to human reviewers before they affect real-world decisions.
Approval Dashboards: Operators can review recommendations, inspect supporting information, and approve or reject AI-generated outputs.
Manual Override Functions: Authorized users can intervene when the system produces an unsafe, inaccurate, or incomplete recommendation.
Role-Based Access Control: Different roles can be assigned different permissions for viewing, approving, editing, auditing, or disabling AI functionality.
Escalation Workflows: Uncertain or high-impact cases can be routed to senior reviewers, compliance officers, medical professionals, supervisors, or administrators.
Kill-Switch Logic: In high-risk environments, the system should include a clear mechanism for pausing or disabling AI operations.
This matters across industries. In manufacturing, a supervisor may need to stop an AI-driven quality control workflow. In healthcare, a clinician must remain responsible for clinical judgment. In logistics, a human operator may need to override an automated routing recommendation when real-world conditions change.
Human oversight is only meaningful when it is usable. If the person responsible for supervision cannot understand, access, or override the AI system in time, the architecture has failed.
5. Architectural Cybersecurity Under Article 15
Article 15 requires high-risk AI systems to meet appropriate levels of accuracy, robustness, and cybersecurity. For AI products, this goes beyond standard application security.
AI systems face specific attack vectors and failure modes. A secure architecture must account for them from the beginning.
Prompt Injection Protection: Generative AI workflows should be hardened against malicious instructions that attempt to override system rules or expose sensitive information.
Adversarial Manipulation Defense: AI models should be tested against inputs designed to mislead, confuse, or manipulate the system.
Data Poisoning Controls: Training and operational data pipelines should be protected from corrupted or intentionally manipulated data.
Unauthorized Model Drift Prevention: The system should control when models are updated, retrained, fine-tuned, or reconfigured.
Access Control and Authentication: Only authorized users should be able to change prompts, models, thresholds, datasets, workflows, or deployment settings.
Monitoring and Alerting: The system should detect unusual behavior, performance degradation, abnormal usage patterns, or unexpected output changes.
Third-Party Dependency Review: If the system uses external AI APIs or cloud models, those dependencies must be documented, monitored, and secured.
This is why custom AI compliance cannot be solved by legal review alone. The regulation creates legal obligations, but the response must be technical: secure architecture, controlled data pipelines, audit-ready logs, human oversight, documentation, and lifecycle monitoring.
Navigating the Value Chain: Providers vs. Deployers
A key part of Regulation (EU) 2024/1689 is understanding who carries which responsibility. In custom software development, this can be misunderstood.
The commissioning company often acts as the legal Provider if it places the AI system on the market or puts it into service under its own name or trademark. The same company, or another professional organization, may act as the Deployer if it uses the AI system under its authority.
Lionwood Software usually functions as the execution partner. Its role is to provide the technical infrastructure, software architecture, documentation support, data controls, security measures, and development processes that help the client meet the obligations attached to its legal role.
The exact role allocation should be clarified contractually and technically during the Discovery Phase.
| Legal role | What it means | Core requirements to consider | How Lionwood supports the technical side |
|---|---|---|---|
| Provider | The organization that develops or has an AI system developed and places it on the market or puts it into service under its own name or trademark. | Risk management, technical documentation, data governance, automated logging, transparency, human oversight, cybersecurity, conformity assessment where required, and post-market monitoring. | Builds the technical architecture, documentation-ready system design, logging mechanisms, security controls, and workflow logic needed to support provider obligations. |
| Deployer | A professional organization that uses an AI system under its authority. This is not the same as an end retail consumer. | Use the system according to instructions, ensure human oversight, maintain automatically generated system logs for at least 6 months under Article 26 where such logs are under the deployer’s control, and monitor operations for unexpected risks. | Designs dashboards, access controls, monitoring tools, log access, escalation paths, and override mechanisms that help Deployers operate AI responsibly. |
| Importer | An EU-based entity that places an AI system from a non-EU provider onto the EU market. | Verify that the Provider has completed required conformity, documentation, instructions, and identification obligations before placing the system on the market. | Supports technical due diligence, system review, documentation preparation, and adaptation of non-EU AI systems to EU expectations. |
| Distributor | A supply-chain actor that makes an AI system available on the EU market without being the Provider or Importer. | Check that required documentation, instructions, markings, and obvious compliance elements are present before making the system available. | Helps prepare technical materials, product information, system documentation, and operational guidance for distribution partners. |
This matrix matters because software architecture should reflect the actual legal role. A Provider needs conformity-oriented documentation and full system traceability. A Deployer needs operational control, logs, monitoring, and human oversight. Importers and Distributors need reliable technical evidence that the system they handle is not a compliance black box.
Compliance Is Becoming a Competitive Asset
Regulation (EU) 2024/1689 is often discussed as a legal burden. For companies building serious AI products, that view is too narrow.
Compliance is becoming a commercial advantage. Enterprise buyers, public-sector clients, investors, and procurement teams will increasingly prefer AI systems that can prove how they handle data, logs, human oversight, security, transparency, and lifecycle monitoring.
A compliant-by-design AI system is easier to assess, easier to trust, easier to scale, and easier to integrate into regulated business environments.
For custom software development, the practical lesson is clear: do not retroactively patch compliance onto your software. Build the technical foundation from day one.
CTA: Don’t retroactively patch compliance onto your software. Contact Lionwood Software today to structure an AI architecture that is compliant-by-design from day one.
