At some point a national competent authority will ask a mid-market organisation to produce the person responsible for its AI compliance programme. They will ask who classified the AI systems, who signed the declaration of conformity, and who approved the risk management framework. In some organisations the honest answer will be that nobody did, because the programme was generated by AI and never reviewed by a person with the authority to own it.
On timing, the high-risk conformity regime described below is not yet in application. Following Regulation (EU) 2026/1744, obligations for Annex III standalone high-risk systems apply from 2 December 2027, and for Annex I embedded systems from 2 August 2028. The Article 5 prohibitions and the Article 50 transparency obligations apply now. The accountability question is therefore one to answer before the regime bites rather than after it.
The accountability gap
The EU AI Act is explicit about accountability. Article 16 sets out the obligations of providers of high-risk systems. Article 26 sets out the obligations of deployers. Article 43 governs conformity assessment. Article 47 requires the provider to draw up a written EU declaration of conformity, and in doing so to assume responsibility for the system’s compliance. Article 48 governs CE marking, and Article 49 registration in the EU database. At every stage the regulation assumes a natural or legal person is taking responsibility.
This is not unique to the AI Act. DORA places ultimate responsibility for the ICT risk management framework on the management body of the financial entity under Article 5. NIS2 requires management bodies to approve and oversee cybersecurity risk management measures under Article 20, and requires member states to ensure they can be held liable for failures. GDPR assigns accountability to the controller under Article 24 and, where one is appointed, involves the Data Protection Officer under Article 37. Across every major EU framework, the common thread is that a named individual or body must be accountable for the programme.
AI cannot fill this role. It can produce the documentation, generate the risk assessments, and draft the declaration of conformity. It cannot sign it. It cannot answer questions at a supervisory meeting. It cannot explain why a particular risk was rated medium rather than high. It cannot defend a classification decision when a regulator challenges it.
What regulators look for
Supervisors do not assess compliance by reading documents alone. They test whether the organisation understands its obligations, has made informed decisions about how to meet them, and can show those decisions being implemented in practice.
Understanding. Can the responsible person explain, in their own words, why the organisation’s AI system is classified as high-risk? Can they set out which obligations apply and how each has been addressed? A document that says the right things evidences that a document exists.
Decision rationale. Can the organisation explain why specific mitigations were chosen, why certain controls were implemented and others were not, and why the residual risk was accepted? Those are judgements, and the test is whether they were exercised by someone who understood the context.
Operational evidence. Is the programme actually running or does it exist only on paper? Are risk assessments reviewed at the stated frequency? Are incidents detected, classified and reported? Do changes to the AI system trigger a compliance review? Expect a request for logs, reviews, reports and records, not only the policy describing the process.
Board-level exposure
The accountability dimension is sharpening across all three regimes. Under DORA the management body must approve and oversee the ICT risk management framework and bears ultimate responsibility for it, which calls for demonstrable oversight rather than passive awareness. Under NIS2, member states must ensure that management bodies can be held liable for failures to comply with cybersecurity risk management obligations. Under the AI Act, drawing up the declaration of conformity is the provider assuming responsibility for the system meeting the requirements.
Boards and senior executives who allow a compliance programme to be produced entirely by AI, without expert review, operational validation, or named ownership, are carrying that exposure themselves. If the programme fails under scrutiny, the question will not be why the AI got it wrong. It will be why nobody checked.
An illustrative scenario
The following is a worked illustration rather than an account of a real engagement. Morclear has no clients to draw case studies from and does not invent them.
An organisation deploys a credit scoring AI system, which falls within Annex III. It uses AI tools to generate the risk management framework, technical documentation, and conformity assessment. The output looks professional and the board approves the programme on the strength of it.
Some time later a consumer complaint triggers a regulatory inquiry, and the national competent authority requests the compliance file. The technical documentation describes risks generically rather than as they arise in the actual deployment. The bias monitoring methodology references metrics that were never measured. The human oversight procedure describes a review process that does not match how the system is operated.
The regulator asks who conducted the risk assessment, who validated the bias monitoring methodology, and who approved the human oversight procedure. The compliance team points at the documentation. The regulator points at the declaration of conformity and asks the signatory to account for the discrepancies. The signatory cannot, because they signed a document they did not fully understand, based on generated content they did not fully review.
Nothing in that sequence requires bad faith. It is what happens when documentation is produced faster than it can be understood.
The alternative
The alternative is straightforward. Use AI to handle the volume, generating documentation, mapping obligations, detecting overlaps, and producing reports. Then have a compliance professional review every output, validate it against your situation, interpret the regulatory context, and take accountability for the result.
When the regulator asks who signed off, the answer is a named professional who reviewed the documentation, understood the risks, made informed decisions, and can defend them under scrutiny. That is what CORA™ is built to produce.
The compliance professional with AI beats AI without a compliance professional, and the accountability question is where that difference becomes visible.
Primary Regulatory Sources
Morclear resources are independently produced. They do not constitute legal, regulatory, financial, or professional advice.