Back to Blog
Article·22 October 2026·By Mehmet Menemenci

Before Launch Day: Why AI Regulation Must Begin at Design

AI regulation as a continuous process, part 1: design and development

Engaging too late

Regulatory engagement can occur very late in the AI development cycle. Ireland's Data Protection Commission (DPC) reports that most of its AI supervision engagements with companies have taken place shortly before the anticipated launch. At the same time, the report states that 95 per cent of AI engagements were able to launch without delay due to DPC engagement. By that stage, choices about data, purpose and performance may already have shaped the risks of the system.

Should regulation come in after the system has been built, or should it be used to shape the design of the system from the beginning? This article argues that AI regulation should not be limited to checking whether a finished system complies with the relevant rules; it should also influence the decisions that determine how the system operates, what risks it generates and how those risks are addressed.

What does 'regulation by design' mean?

What “regulation by design” entails is to consider the relevant legal requirements at the stage of design rather than dealing with compliance at that later stage.

The GDPR provides an example of this. According to Article 25, the controller must establish appropriate technical and organisational measures when deciding how personal data will be processed and also during the processing itself. It is also necessary to apply data protection by default, this involving the guarantee that personal data is restricted to what is necessary for each particular purpose. The European Data Protection Board then explains how these obligations influence the design and organisation of the data processing.

The EU AI Act requirements for high-risk AI systems are risk management, data governance, technical documentation and human oversight (Articles 9, 10, 11 and 14) and a quality management system (Article 17). For systems which are intended to be placed on the market or put into service as high risk, identifying the relevant requirements early on can help to inform development decisions as to how the risks are to be assessed, how the data is to be selected and governed and how human oversight is to be integrated into the system. Not every decision will require legal review, but applicable obligations should inform decisions that affect compliance and the risks posed to people.

Article 2(8) excludes research, testing and development activities involving AI systems or models before they are placed on the market or put into service. These activities must comply with applicable EU law, and testing in real-world conditions is not covered by the exclusion. The AI Act generally does not apply to pre-market activities, but decisions made during development can affect whether the final system complies with the Act.

From legal requirements to design decisions

Think of an AI recruitment tool that has been trained on historical hiring data. If that data contains a history of discrimination or exclusion, the tool may in fact replicate those very same patterns when it comes to ranking candidates. It might be spotted in a review prior to launch, but by that stage the organisation may have already built their product on the data and the methods that generated it.

Research into algorithmic hiring has identified several factors that can lead to bias, including the over-representation of frequent users in platform training data, missing information about less active job seekers, and biased decisions at earlier recruitment stages that affect subsequent stages of the process. Certain AI systems intended for recruitment or selection are classified as high-risk under Annex III, the AI Act's list of high-risk uses. The Act's high-risk requirements, including Article 14's human-oversight requirements, are scheduled to apply to these systems from 2 December 2027 under Regulation (EU) 2026/1744. This shows why a final check alone is not enough.

A development stage approach would ask: are the data appropriate for the purpose in hand? How will the issue of unequal outcomes be dealt with? What happens when the recommendations are not reliable? Where can a human step in?

None of these measures will guarantee fairness, as bias is notoriously difficult to spot and no single check captures the whole picture. They do, however, provide the opportunity to deal with potential problems that are foreseeable whilst the changes are still possible.

The same applies to privacy. Defining a system's purpose before collecting data helps determine which data are necessary and which lawful basis, meaning the legal justification permitted under the GDPR, if any, can support the processing. The GDPR principles of purpose limitation and data minimisation guide these decisions, while Article 6 sets out the lawful bases for processing.

What does it look like in practice?

In January 2023 the US National Institute of Standards and Technology (NIST) launched its Artificial Intelligence Risk Management Framework (AI RMF 1.0) as a practical and voluntary framework. The framework consists of four functions: Govern, Map, Measure and Manage. The GOVERN function is applicable throughout all stages of the AI lifecycle and thus affects the other functions. Although the NIST Playbook offers recommended actions for the application of the framework, neither of the two resources takes the place of legal obligations.

An organisation developing an AI recruitment tool might be asked to take on the responsibility of risk management (Govern), identify those who could be affected (Map), test the model's performance and potential bias among different groups (Measure), and deal with any problems before the tool is put into use. In the case where testing shows that there are disparities, the organisation could then examine its data, modify the model and carry out more testing before making a decision as to whether the tool is ready to be used. The objective is not to stick to a strict checklist, but rather to incorporate risk management into the development decisions made before launch.

A real-world example: Ireland's data protection regulator

In its September 2026 report, the DPC describes a controller who, when developing an AI model based on users' personal data in 2021, submitted a data protection impact assessment (DPIA) for the intended training and received feedback from the DPC at the design stage. The following version of the DPIA took that feedback on board and dealt with the issue of model fine-tuning, which led to a great deal less personal data being processed.

The DPC also issued recommendations relating to transparency, the rights of data subjects and retention. Upon the controller later submitting a DPIA in connection with the proposed deployment, the DPC then made additional recommendations concerning data minimisation, proportionality, necessity and the right to object. The controller revised the DPIA, carried out a pilot trial of the model and launched the feature after taking the DPC's advice.

The report treats this as a matter falling within the scope of GDPR supervision, not as an evaluation under the AI Act. It does not demonstrate that early involvement always avoids problems or speeds up development; rather, it does show that regulatory feedback can affect the way personal data are processed during the period when the project is still adaptable. More generally, the DPC believes that a minimum lead time of eight weeks is necessary for substantial engagement.

Design is the beginning, not the end

It is impossible to predict all possible risks before a product is launched, since real-world conditions can differ from those assumed during the development phase and any weaknesses which were not detected during testing might appear after the system has been put into use. According to Article 72 of the EU AI Act, providers of high-risk AI systems must set up a post-market monitoring system that is appropriate to the situation, involving the systematic collection, recording and analysis of relevant performance data throughout the lifetime of the system.

It should not be taken as a substitute for the safeguards that are in place at the development stage. Article 9 presents risk management as a continuous and iterative process and connects it with the evaluation of risks that have been identified through post-market monitoring. At the development stage, it is necessary to identify and reduce foreseeable risks, while monitoring offers evidence of how the system functions in practice and whether further action becomes necessary. Both aspects are essential to continuous risk management.

Conclusion

AI regulation should not start at launch. By that point, decisions around data, design and performance may already have had an impact on the risks associated with the system. The relevant rules should be considered from the outset, the system should be tested for problems and appropriate safeguards put in place. Post-launch monitoring is vital, as real-world evidence may reveal risks that were not apparent during the development process. Regulation should be part of the AI development process at every stage, enabling organisations to prevent harm while they still have the opportunity to make changes.

Sources
Back to all posts
Join Us

Join the Global AI³ Network