Conformity assessment failure is a likely outcome for first-time AISDP preparation, particularly for systems developed before the AI Act. Three pathways exist: remediation and re-assessment for bounded non-conformities, deployment deferral for fundamental issues requiring rearchitecture, and system withdrawal when non-conformities are irremediable. Notified body rejection carries additional consequences for systems requiring mandatory third-party assessment.
Remediation with conditional approval is the most common pathway following an assessment that identifies non-conformities that cannot be resolved within the planned timeline.
Remediation with conditional approval is the most common pathway following an assessment that identifies non-conformities that cannot be resolved within the planned timeline. This is not a theoretical possibility but a likely outcome for organisations undertaking aisdp preparation for the first time, particularly for systems developed before the AI Act's requirements were well understood. The assessment framework must include a defined pathway for this outcome.
The AI Governance Lead faces a decision with three possible outcomes. The most common is remediation and re-assessment, where the non-conformities are remediated, the affected AISDP modules are updated, the remediated areas are re-assessed, and the assessment proceeds to completion. This pathway is appropriate when the non-conformities are bounded and the remediation is technically feasible within a reasonable timeframe. The AI System Assessor scopes the re-assessment to the remediated areas; a full re-assessment is not necessary unless the remediation affected the system's architecture or intended purpose.
Deployment deferral is the appropriate pathway when non-conformities are fundamental: the system's architecture does not support the required human oversight, the training data cannot be shown to be representative, or the model's explainability is insufficient for the deployment context.
Deployment deferral is the appropriate pathway when non-conformities are fundamental: the system's architecture does not support the required human oversight, the training data cannot be shown to be representative, or the model's explainability is insufficient for the deployment context. In these cases, remediation may require rearchitecture or redevelopment, and the system cannot be deployed until the fundamental issues are resolved. The AI Governance Lead communicates the deferral to the Business Owner including the deployment timeline implications and the resource requirements for remediation. Deployment deferral is a significant business decision, but deploying a non-conforming system carries greater risk under the Article 99 penalty framework.
System withdrawal is the most severe pathway. If the non-conformities are irremediable within the system's economic or technical constraints, the system may need to be withdrawn from the AISDP preparation process entirely. This may lead to decommissioning the system, replacing it with an alternative that can achieve conformity, or reclassifying the system if the assessment reveals that the actual risk profile differs from the initial classification, in which case a CDR review may be appropriate. The AI Governance Lead documents the withdrawal decision with the rationale, the non-conformities that triggered it, and the alternatives considered.
For systems subject to third-party CONFORMITY ASSESSMENT, including biometric identification systems under Annex III point 1 or systems where the provider voluntarily engages a notified body, the notified body may decline to certify the system.
For systems subject to third-party conformity assessment, including biometric identification systems under Annex III point 1 or systems where the provider voluntarily engages a notified body, the notified body may decline to certify the system. A notified body rejection carries greater consequence than an internal assessment failure for three reasons.
First, the rejection is documented in the notified body's records, creating a permanent compliance history entry for the system. Second, the rejection may be communicated to the competent authority depending on the notified body's reporting obligations, potentially triggering regulatory scrutiny beyond the assessment process itself. Third, the provider cannot self-certify as an alternative for systems where third-party assessment is mandatory, meaning the rejection blocks market placement entirely.
When a notified body identifies non-conformities, it will typically provide a detailed report specifying the deficiencies. The provider should treat this report as a remediation plan, address each deficiency systematically, and resubmit for assessment. Multiple rounds of review and remediation are common in practice. The provider should budget for at least two to three assessment cycles when planning for notified body engagement, as the initial submission rarely achieves certification without revision.
No. The AI System Assessor scopes re-assessment to the remediated areas only, unless the remediation affected the system's architecture or intended purpose.
Not for systems where third-party assessment is mandatory, such as biometric identification for law enforcement. The provider must address the deficiencies and resubmit.
Document the withdrawal decision with the rationale, the non-conformities that triggered it, and the alternatives considered. This may lead to decommissioning, replacement, or reclassification.
When non-conformities are fundamental, such as architecture that cannot support human oversight or training data that cannot be shown to be representative.
The rejection is documented in the notified body's records, may be communicated to the competent authority, and the provider cannot self-certify as an alternative.
At least two to three cycles when engaging a notified body, with multiple rounds of review and remediation being normal.
Accuracy, Robustness, Cybersecurity
