The EU AI Act has moved from abstract regulation to concrete engineering constraint. For organisations with live AI systems, the key question is no longer "does this apply to us?" but "how far are we from compliance, and what exactly must change?"
A structured gap analysis gives product managers, engineering leads and compliance teams a shared, technical view of readiness. Done correctly, it becomes a design artefact, not a paperwork exercise.
Below is a practical 7‑step methodology tailored to existing AI products already in production or late-stage development.
1. Map the AI System and Its Context
Gap analysis starts with ruthless clarity about what you are analysing. Under the EU AI Act, scope hinges on how an AI system is placed on the market, used and integrated into a broader socio‑technical context.
Create a concise system dossier covering:
•
Functional scope: what decisions, predictions or content the system generates.
•
End‑to‑end data flow: sources, pre‑processing, models, post‑processing, human touchpoints.
•
Deployment topology: cloud/on‑prem, edge, embedded, API‑only, third‑party integrations.
•
User roles: deployer, end‑user, affected persons, human reviewers.
•
Geography and customers: where the system is used, by whom, and for what regulated domains (e.g. HR, credit, healthcare).
This should fit into a 3–5 page technical document that engineering signs off. Avoid marketing abstractions; regulators and auditors will test actual behaviour, not slideware.
2. Determine AI Act Classification and Risk Level
With the system mapped, classify it according to the EU AI Act’s definitions and risk tiers.
2.1 Confirm It Is an "AI System"
Under the Act, an AI system is software that uses machine learning, logic‑ and knowledge‑based or statistical approaches to generate outputs such as predictions, content, recommendations or decisions influencing environments.
If your product contains:
•
ML models (supervised, unsupervised, reinforcement learning), or
•
rule‑based systems with complex logic and optimisation,
it almost certainly qualifies.
2.2 Identify Prohibited, High‑Risk, Limited‑Risk or Minimal‑Risk Uses
Work through these questions:
•
Does the system fall under any prohibited practices? (e.g. social scoring by public authorities, manipulative techniques targeting vulnerabilities). If yes, you have a strategic product problem, not just a gap.
•
Does it match a high‑risk use case under Annex III? For example:
- Biometric identification and categorisation. - AI used in recruitment, promotions or worker management. - Creditworthiness and access to essential services. - Safety components of products subject to sectoral safety regulations.
•
Is it a general‑purpose AI (GPAI) model used or licensed broadly?
•
Is it a limited‑risk system, mainly requiring transparency (e.g. chatbots where users must be informed they are interacting with AI)?
Document classification decisions with references to specific EU AI Act articles and annexes. This classification drives the depth of your gap analysis; high‑risk systems face the most stringent requirements.
3. Build a Control Matrix Aligned to the Act
Once you know your risk tier, derive a control matrix that maps textual obligations in the Act to concrete, testable controls for your product.
For high‑risk systems, systematically cover at least:
•
Risk management system: continuous risk identification, analysis, mitigation and monitoring.
•
Data and data governance: training, validation and testing datasets, representativeness, biases, quality and lineage.
•
Technical documentation: design, training procedures, evaluation, limitations, interfaces.
•
Record‑keeping and logs: traceable logs of operation, inputs/outputs, model versions.
•
Transparency and information to users: clear instructions for deployers and users, including limitations.
•
Human oversight: defined human roles, intervention mechanisms, override capabilities.
•
Accuracy, robustness and cybersecurity: performance metrics, stress tests, adversarial resilience.
Represent this in a simple table or spreadsheet:
•
Column A: EU AI Act requirement (article + brief description).
•
Column B: Interpreted control (what the system must support or provide).
•
Column C: Responsible function (product, engineering, data science, security, legal).
This becomes your blueprint for the gap analysis.
4. Assess Current State Against Each Control
Now, run a structured assessment against the matrix. Treat it like a technical design review, not a legal questionnaire.
For each control, capture:
•
Current implementation: what exists today, with links to code, runbooks, policies and tickets.
•
Evidence: artefacts proving implementation (e.g. model cards, test reports, logging config, SOPs).
•
Effectiveness: qualitative judgement (e.g. robust / partial / ad‑hoc / absent).
•
Residual risk: what could still go wrong for users or affected persons.
Typical high‑friction areas in existing products include:
•
No formal risk register specific to the AI system.
•
Data provenance undocumented or scattered across teams.
•
Sparse or non‑standard model documentation.
•
Logging focused on performance, not accountability and traceability.
•
Human‑in‑the‑loop processes that exist in theory but not in SOPs.
This step is where engineering and compliance must be in the same room. Product managers should challenge whether features support safe and compliant use in realistic scenarios, not only in test conditions.
5. Quantify and Prioritise Compliance Gaps
With an initial assessment complete, turn findings into a prioritised backlog. For each gap:
- Critical: could render the system non‑compliant or illegal. - Major: significant deviation from requirements; likely regulatory scrutiny. - Minor: documentation or process refinements.
•
Assess implementation effort: low, medium, high, involving the teams who will do the work.
•
Estimate business impact: dependency on key customers, deployment scale in the EU, and strategic relevance.
Use this to build a risk‑based roadmap. Typically, early focus should be on:
•
Eliminating any proximity to prohibited practices.
•
Establishing a minimal, auditable risk management framework.
•
Implementing core logging and traceability in production systems.
•
Providing user‑facing transparency where currently absent.
Link each backlog item to its corresponding article in the EU AI Act, so stakeholders can see exactly why work is being done and what risk it mitigates.
6. Design Remediation Across Product, Process and Platform
Remediation is rarely just a policy update. For existing AI systems, expect interventions at three levels:
- Embed clear disclosures when users interact with AI. - Add explanations or confidence indicators where required. - Provide clear error states and escalation paths to humans.
1.
Model and Data Lifecycle
- Introduce structured data governance: dataset catalogues, bias assessments, lineage. - Standardise model documentation (e.g. model cards, evaluation reports, deployment checklists). - Implement regular post‑deployment monitoring for drift, bias and performance declines.
1.
Platform and Operations
- Extend logging to support audit trails and user complaint investigations. - Harden security controls around models, training data and pipelines. - Embed EU AI Act checks into CI/CD: pre‑deployment gates for documentation, tests and approvals.
Design remediation as reusable capabilities, not one‑off fixes for a single product. This cuts long‑term compliance costs and accelerates future AI initiatives.
7. Institutionalise Continuous Compliance and Governance
The EU AI Act expects ongoing conformity, not a one‑time certification. Once gaps are addressed, formalise continuous governance.
Key elements include:
•
Designated roles: a named AI compliance owner per product, plus cross‑functional steering.
•
Periodic reassessment: scheduled reviews when models, data, use cases or jurisdictions change.
•
Incident management: a clear process and SLA for handling adverse events and complaints.
•
Evidence management: a central repository of technical documentation, logs samples, reports and approvals, ready for market surveillance authorities or notified bodies.
•
Training and playbooks: concise guidance for engineers, data scientists and product managers on how EU AI Act requirements map to everyday decisions.
By embedding these into standard product lifecycle stages (discovery, design, build, deploy, monitor), you reduce the risk that new features quietly erode compliance over time.
Conclusion: From Gap Analysis to Strategic Advantage
An EU AI Act gap analysis is more than a defensive legal exercise. It forces clarity about how your AI product behaves in the real world, how robust your engineering practices are, and how accountable you can be to regulators, investors and users.
Following this 7‑step methodology, product managers, engineering leads and compliance teams can move from anxiety about regulation to a structured, evidence‑driven plan for alignment. The result is not only reduced regulatory exposure, but AI systems that are more trustworthy, maintainable and commercially resilient.
As enforcement timelines narrow, organisations that treat gap analysis as an architectural discipline, rather than a tick‑box audit, will be best positioned to scale AI safely across markets, fully aligned with the forward‑looking vision that guides ON TIME TECHNOLOGY LTD.