Practical Read of the EU AI Act – Part III

Originally published on LinkedIn on 2025-06-05. Republished here as part of the EU AI Act series.

Let’s now explore how these regulatory requirements translate into practical engineering challenges and technical implementations that teams must navigate. I will try examine the concrete steps needed to achieve compliance, and see how theoretical frameworks become tangible development tasks and architectural decisions that engineering teams must address in their day-to-day work.

Also, I received some feedback to make this more concise. I’ll try but when the need to expand on a topic is needed, I will do so.

Provider & Deployer Responsibilities: Engineering Compliance and Ensuring Safe Use (Articles 16-27)

The “high-risk” classification for CreditWise propels TrustFund AI into the core of the Act’s operational demands: the extensive obligations for providers detailed primarily in Articles 16-27.

For InnovateAI Corp, understanding these provider obligations is crucial, as any future high-risk application of ConverseAI would necessitate the same rigorous approach.

Take those articles as a blueprint for building and maintaining trustworthy high-risk AI.

Core Provider Obligations: Engineering Quality, Documentation, and Responsiveness (Articles 16, 17, 18, 19, 20, 21)

Article 16 acts as the provider’s compliance dashboard.

TrustFund AI must ensure CreditWise meets all technical requirements from Articles 8-15. Central to this is a technically robust Quality Management System (QMS):

• comprehensive up-to-date documentation,
• auditable logs,
• successful conformity assessment,
• a formal EU declaration of conformity,
• the visible CE marking (if and when needed),
• registration in the EU database, and
• a readiness for swift corrective actions.

Engineering the AI Quality Management System (Article 17)

TrustFund AI’s engineering and compliance teams collaborate intensively on their QMS, as mandated by Article 17.

This is far more than a procedural overlay; it’s about codifying quality, safety, and compliance into every stage of CreditWise’s lifecycle.

• AI-Specific SDLC Integration: The QMS is built around an AI-specific Software Development Lifecycle. This includes dedicated stages for:

• Version Control & Reproducibility: Maria, their engineering lead, insists on “military-grade version control for everything.” This means:
• MLOps and Automation: The QMS procedures are embedded within TrustFund AI’s MLOps framework:
• Technical Specifications & Standards (Art. 17(1e)): The QMS details which harmonized standards (Article 40) or common specifications (Article 41) are applied. If not, it documents the alternative technical solutions used to meet each requirement, providing detailed justifications but this will fall on you as the developer or provider. See 41(5).
• Data Management Procedures (Art. 17(1f)): This section of the QMS details the technical architecture of their data pipelines, data storage solutions (ensuring security and integrity), data annotation and labelling workflows (if any), and their specific algorithms for data cleaning and aggregation.
• Security of Supply & Resource Management (Art. 17(1l)): For TrustFund AI, this involves ensuring reliable access to validated financial data sources and contingency plans if a primary data provider fails. It also covers securing the computational resources needed for model retraining and operation.
• Accountability Framework (Art. 17(1m)): Clear assignment of responsibilities for QMS adherence across roles.

For a financial institution like TrustFund AI, elements of this QMS can integrate with existing financial regulatory frameworks, but AI-specific risk management (Article 9), post-market monitoring (Article 72), and incident reporting (Article 73) must be explicitly covered.

Deep Dives into Documentation and Logs (Articles 11, 18, 12, 19):

The technical documentation (Article 11, with details in Annex IV) is the bedrock of proof.

TrustFund AI ensures it contains:

• Detailed algorithmic design choices, including mathematical formulations if necessary for clarity.
• Model architecture diagrams, data flow diagrams illustrating how data is processed through CreditWise.
• Specifications of APIs used by or exposed by CreditWise.
• Results from their extensive testing, including specific metrics for bias across different demographic slices, confusion matrices for classification tasks, and results of robustness tests (e.g., performance under noisy input conditions).

This documentation, along with QMS records and conformity certs, must be available to authorities for 10 years.

Logging (Article 12, Article 19) is engineered for comprehensive traceability:

CreditWise implements structured logging (e.g., JSON format) for all significant events:

• Every prediction request with input features (pseudonymized where appropriate),
• Results for each score/decision,
• Versions of the model(think DataDog, Grafana, MLFlow, etc),
• Data used for the prediction,
• Human oversight interactions (e.g., an override of a decision),
• Any system errors or anomalies.

These logs are stored securely, with tamper-evident mechanisms, and are queryable for auditing. The system is designed so logs under provider control are retained for at least six months.

Swift Responses: Corrective Actions and Authority Cooperation (Articles 20, 21).

If a non-compliance or risk emerges in CreditWise, TrustFund AI must act decisively.

Their QMS includes incident response plans.

They must also provide authorities with all necessary information, potentially including direct, secure access to specific logs or documentation to demonstrate conformity.

All information shared is subject to confidentiality.

Global Market Entry: Roles Beyond the Original Provider (Articles 22-25)

We have been focusing on CredtiWise due to their high-risk nature, but let’s switch gears a bit into InnovateAI Corp (the US-based).

As a non-EU provider, InnovateAI Corp, if targeting the EU with a high-risk version of ConverseAI, must appoint an EU-based authorized representative and would need to set up a secure portal for its EU representative.

This portal provides access to:

• Latest versions of ConverseAI’s technical documentation,
• EU declaration of conformity (this is an important topic we will discuss later),
• Conformity assessment certificates,
• Potentially a controlled interface to query non-sensitive operational logs or system performance metrics relevant for compliance reporting.

The portal need to have a strong authentication and encryption, with audit trails for access.

The representative is contractually empowered to perform tasks like verifying documentation and cooperating with EU authorities.

Importer and Distributor Checks (Articles 23, 24)

Entities bringing ConverseAI into the EU market (importers) or distributing it (distributors) have verification duties (CE mark, documentation).

This creates multiple checkpoints in the supply chain and a need to understand the requirements.

Provider Status Changes (Article 25)

This article is crucial when AI systems are modified, like we saw in Part I.

An entity becomes a “provider” if they substantially modify a high-risk AI system or change a non-high-risk system into a high-risk one.

Let’s explain a bit more the part of Substantial Modification for a company like an AI company like CreditWise or ConverseAI, a substantial modification could be triggered by:

• Architectural Overhaul: Changing the core neural network architecture significantly (e.g., from a simple logistic regression to a large deep learning model).
• Fundamental Retraining on New Data Domains: If CreditWise, initially trained on data for personal loans, is retrained with entirely new datasets to also assess small business loans, changing its risk profile and performance characteristics in ways not covered by the initial conformity assessment.
• Altering Core Optimization Function: Changing the primary objective the model is trained to optimize if it materially affects its risk profile or fairness.
• Adding New High-Impact Input Features: Incorporating previously unused types of sensitive data that significantly alter decision-making.

Routine model updates or retraining with data from the same distribution within pre-defined performance boundaries and documented in the initial assessment (as per Article 43(4) and Annex IV, point 2f) would generally not be “substantial.”

This is where this type of legislation gets tricky and elements like this one are buried in it, and if you are not paying attention it can get you in trouble.

TrustFund AI’s MLOps pipeline must include governance checkpoints:

• If a planned model update involves changes flagged as potentially “substantial” (e.g., a data drift score exceeding a critical threshold, or a significant change in the feature set),
• it triggers a manual review by the compliance team to assess if a new conformity assessment is needed before deployment.

Third parties supplying tools or components (e.g., a specialized fraud detection module integrated into CreditWise) must provide necessary information and assistance to the high-risk AI provider via written agreement, unless it’s a non-GPAI open-source component.

In Action: Deployer Duties and Assessing Real-World Impact (Articles 26, 27)

Once an EU bank licenses and deploys CreditWise, it becomes a deployer with its own critical obligations under Article 26.

• Usage According to Instructions & Human Oversight: The bank must use CreditWise as per TrustFund AI’s instructions and assign competent, trained staff for human oversight as explain in Part II.
• Input Data Responsibility (Art. 26(4)): If the bank combines CreditWise’s output with its own customer data inputs, it must ensure this additional input data is relevant and sufficiently representative for the specific context in which CreditWise is being used.

The bank might need its own data validation pipelines for any local data it feeds into or uses alongside CreditWise. TrustFund AI might provide APIs that allow the bank to get performance metrics or explainability outputs based on the specific data segments the bank is processing.

• Monitoring and Reporting (Art. 26(5)): The bank must monitor CreditWise’s operation. If it suspects a risk or a serious incident occurs (e.g., discovers CreditWise is systematically producing biased scores for a local demographic not well-represented in the original training data, leading to harm), it must inform TrustFund AI (or distributor) and the relevant market surveillance authority, and suspend use.

Deployers may need dashboards or APIs from TrustFund AI to monitor key performance and fairness metrics in their specific operational context. Secure communication channels for incident reporting are also vital.

• Log Keeping (Art. 26(6)): The bank must keep logs generated by CreditWise under its control (e.g., specific loan application processing logs) for at least 6 months.

Fundamental Rights Impact Assessment (FRIA) (Article 27)

Before deploying CreditWise, the bank must perform an FRIA.

This is a proactive analysis of:

• How CreditWise will be integrated into their loan application process.
• The categories of individuals affected.
• Specific risks to fundamental rights (e.g., discrimination in access to credit, impact on privacy, right to an explanation). This assessment must consider the information provided by TrustFund AI in its instructions for use (Article 13).
• The planned human oversight measures by the bank.
• Measures to mitigate identified risks (e.g., appeal processes for denied loans, specialized training for loan officers overseeing AI decisions).

The FRIA forces the bank to look beyond mere technical performance and consider the societal impact.

The design of CreditWise (e.g., its explainability features, configurability of decision thresholds, robustness of human oversight interfaces) directly impacts the bank’s ability to conduct a meaningful FRIA and implement effective mitigation.

The FRIA results are notified to the market surveillance authority.

The Gatekeepers and the Rulebook: Notified Bodies, Standards, and the Path to CE Marking (Articles 28-49)

So far we have only scratched the surface of the EU AI Act. When you analyze it in depth, you begin to grasp just how massive and complex this legislation truly is. We are not even touching lateral laws or regulations.

Each application requires its own analyzes.

We looked at an approximation of their internal systems for risk management, data governance, technical documentation, logging, transparency for deployers, and human oversight design.

Having engineered CreditWise for accuracy, robustness, and cybersecurity, TrustFund AI now prepares for the formal conformity assessment process.

This involves understanding the role of Notified Bodies and leveraging standards to demonstrate compliance.

Notifying Authorities and Notified Bodies (Articles 28-39)

Before CreditWise can be CE marked and launched, if it requires third-party assessment (as some high-risk AI systems do, particularly those under Article 43(1) where harmonized standards are not fully applied or available, or for specific biometric systems), TrustFund AI would need to engage a Notified Body.

What are Notified Bodies? These are independent organizations designated by EU Member States (via Notifying Authorities established under Article 28) to assess the conformity of certain products (and now, high-risk AI systems) with EU requirements before they are placed on the market. Their role is crucial for ensuring trust and safety.

Most countries have not yet finalized or publicly announced their notifying authorities as of May 2025. The process is ongoing, and updates are expected as Member States meet the August 2025 deadline for designation. Here is all I could find as of this writing:

Technical Competence is Key (Article 31): For a Notified Body to be designated for assessing AI systems like CreditWise, it must demonstrate profound technical competence. This isn’t just about checking paperwork; it includes having personnel with expertise in:

• AI technologies, machine learning algorithms, data science.
• Data governance, quality assessment, and bias detection techniques.
• Cybersecurity principles as applied to AI (e.g., resilience against adversarial attacks, data poisoning).
• Fundamental rights implications and ethical considerations of AI.
• The specific domain of application (e.g., for CreditWise, understanding financial services).
• They must also have robust procedures, ensure impartiality, confidentiality, and have suitable cybersecurity measures themselves.

The Notification Process (Article 30): Notifying Authorities assess and notify suitable conformity assessment bodies to the Commission and other Member States. This includes detailing their specific scope of AI assessment competence.

Operational Obligations (Article 34): Notified Bodies must verify conformity according to the procedures in Article 43 and do so proportionately, especially considering SMEs, but without compromising rigor.

TrustFund AI would select a Notified Body designated for assessing AI systems in the financial services domain or for creditworthiness applications. They would then submit their extensive technical documentation (as per Article 11) and details of their Quality Management System (QMS under Article 17) for scrutiny.

Leveraging Technical Standards and Ensuring Conformity (Articles 40-43)

To streamline compliance, the Act emphasizes the role of harmonized standards and common specifications.

• Harmonized Standards (Article 40): If CreditWise conforms to harmonized standards it is presumed to be in conformity with the AI Act’s requirements covered by those standards. The Commission is tasked with requesting European standardization organizations to draft these standards, covering the Act’s requirements and promoting energy-efficient AI development.

These standards would offer concrete technical specifications. For example, a standard on AI robustness might detail specific testing methodologies for different types of adversarial attacks or define metrics for quantifying resilience. A standard on data governance might specify methodologies for bias assessment in datasets or anonymization techniques. For TrustFund AI’s engineers, adhering to these would provide a clear technical roadmap.

Common Specifications (Article 41): If harmonized standards are lacking, delayed, or insufficient (especially concerning fundamental rights), the Commission can adopt implementing acts to establish common specifications as a fallback. Compliance with these also grants a presumption of conformity. Providers not using these must justify their alternative solutions.

Other Presumptions (Article 42): High-risk AI systems trained and tested on data reflecting their specific geographical/contextual setting are presumed to meet certain data representativeness requirements.

Certification under an EU cybersecurity scheme (e.g., under the Cybersecurity Act) can presume conformity with the AI Act’s cybersecurity requirements.

The Conformity Assessment Itself (Article 43)

This is the formal process to demonstrate CreditWise meets the requirements. The path depends on the system and the provider’s choices:

1. For high-risk AI systems listed in Annex III, point 1 (certain biometrics): If the provider applies harmonized standards or common specifications, they can choose between: An internal control procedure (detailed in Annex VI). OR assessment of the QMS and technical documentation by a Notified Body (detailed in Annex VII).

If standards/specifications are not applied or don’t exist, the Notified Body route (Annex VII) is mandatory.

For other high-risk AI systems in Annex III (like CreditWise, under Annex III, point 5b): Providers generally follow the internal control procedure (Annex VI), which does not involve a Notified Body.

This is a significant point for TrustFund AI. They would meticulously follow Annex VI, verifying their QMS (Article 17) and examining their technical documentation (Article 11) to assess compliance with Chapter III, Section 2 requirements themselves.

For high-risk AI systems also covered by existing EU product safety laws (Annex I, Section A): The AI Act’s requirements are assessed as part of the conformity assessment under those existing laws. Notified Bodies under those laws can assess the AI parts if their competence has been verified.

InnovateAI Corp Technical Consideration: If ConverseAI were ever embedded as a safety component in, say, a piece of machinery (unlikely for its primary function but hypothetically), its AI Act compliance would be assessed alongside the machinery directive compliance.

The Notified Body Assessment (Annex VII – for systems requiring it)

If TrustFund AI did require a Notified Body (e.g., if they didn’t apply relevant standards for an Annex III point 1 system, or if Article 43(2) were amended to require it for their type of system via future delegated acts mentioned in Art. 43(6)), the process would be intense:

• QMS Assessment: The Notified Body assesses TrustFund AI’s QMS (Article 17).
• Technical Documentation Scrutiny: The Notified Body examines the technical documentation (Annex IV). This is where engineering rigor is tested. The Notified Body can request further evidence or tests.
• Access to Data and Models: Crucially for AI, the Notified Body “shall be granted full access to the training, validation, and testing data sets used, including, where appropriate…through API or other relevant technical means“. If necessary and all other means are exhausted, they can even request access to “training and trained models…including its relevant parameters” under strict confidentiality and IP protection. This allows for deep technical dives into how the AI was built and validated.

TrustFund AI would need to design secure APIs or methods for Notified Bodies to inspect datasets and potentially models without compromising IP excessively. This could involve sandboxed environments for model execution or inspection of model architecture and parameters.

Substantial Modifications (Article 43(4)): A Key MLOps Concern

“What if we significantly upgrade CreditWise’s core algorithm or retrain it on a completely new dataset?” asks Ben.

Anya clarifies:

“Any substantial modification to CreditWise after it’s placed on the market triggers a new conformity assessment”. A ‘substantial modification‘ is defined as a change not foreseen or planned in the initial assessment that affects compliance or alters the intended purpose. However, “changes to the high-risk AI system and its performance that have been pre-determined by the provider at the moment of the initial conformity assessment and are part of the information contained in the technical documentation…shall not constitute a substantial modification“.

This is vital for AI systems that continuously learn or are frequently updated. TrustFund AI needs a robust MLOps governance framework.

Their QMS (Article 17) must define processes for managing modifications. If they plan regular model retraining with new data within certain pre-defined boundaries and performance envelopes, and these are documented and assessed upfront (e.g., in Annex IV, point 2f), these updates might not be “substantial.”

Fundamental changes in the model architecture, a switch to a new type of input data not previously assessed, or adapting CreditWise for a completely new financial product would likely be substantial, requiring a new assessment.

Certificates, Declaration, CE Marking, and Registration (Articles 44-49)

Assuming successful conformity assessment (whether internal or via Notified Body):

Certificates (Article 44): If/when a Notified Body is involved, they issue certificates (valid up to 4 years for Annex III systems like CreditWise, 5 for Annex I systems), which can be extended.

They can also suspend/withdraw certificates if non-compliance is found.

• EU Declaration of Conformity (Article 47): TrustFund AI, as the provider, must draw up a written EU declaration of conformity for CreditWise, stating it meets the Act’s requirements. This declaration (contents detailed in Annex V) is their responsibility. It includes AI system name, provider details, statement of conformity, references to standards used, and Notified Body details if applicable.
• CE Marking (Article 48): CreditWise must bear the CE marking to indicate conformity and allow free movement in the internal market. For digitally provided AI systems like CreditWise, a digital CE marking is permissible if easily accessible (e.g., via the app’s interface or a QR code). If a Notified Body was involved, its identification number follows the CE marking.

Aspect CE Marking Requirement under EU AI Act Who applies it? Providers of high-risk AI systems What does it show? Conformity with all applicable requirements of the AI Act Where is it applied? On the system, packaging, documentation, or digitally in a section like the “About” When is it required? Before placing on the EU market or putting into service Notified body number? Required if external conformity assessment was used Legal effect Allows free movement and market access in the EU

• Registration (Article 49): Before placing CreditWise on the market, TrustFund AI (or its authorized representative) must register themselves and CreditWise in the EU database referred to in Article 71.

For InnovateAI Corp, if ConverseAI were classified as high-risk, they’d follow a similar path. If it were also a component of an Annex I product, Article 43(3) outlines how its AI conformity assessment integrates with the product’s existing assessment routes.

Understanding these technical and procedural hurdles is paramount for any company wishing to deploy high-risk AI in the EU.

General Transparency Obligations for Specific AI Systems (Chapter IV, Article 50)

Beyond the stringent regime for high-risk systems, the EU AI Act mandates specific transparency measures for certain AI systems to ensure users are adequately informed when interacting with or being exposed to AI.

These obligations, laid out in Article 50, apply irrespective of whether an AI system is high-risk, aiming to prevent deception and empower users.

Both InnovateAI Corp and TrustFund AI must consider these for their systems:

1. Informing Humans of AI Interaction (Article 50(1)):

Detecting and Marking AI-Generated Content (Article 50(2))

Providers of AI systems (including general-purpose AI systems, covered later in Chapter V) that generate synthetic audio, image, video, or text content must ensure outputs are marked in a machine-readable format and detectable as artificially generated or manipulated.

This should be reliable, interoperable, and robust as technically feasible, considering the state of the art (e.g., watermarks, metadata).

Exceptions apply for standard editing assistance or if authorized by law for law enforcement.

Let’s look at this from a technical Angle*:*

InnovateAI Corp (ConverseAI): If ConverseAI generates summary emails or reports for customers, these would need appropriate machine-readable markers (e.g., specific metadata tags like <dcterms:creator> indicating an AI agent, or a subtle, technically detectable watermark if it generates images/videos for, say, personalized explanations).

• TrustFund AI (CreditWise): If their marketing team uses AI to generate images for advertisements that resemble real people but are synthetic, those images must be marked.

Transparency for Emotion Recognition and Biometric Categorization (Article 50(3)):

Deployers using an emotion recognition system or a biometric categorization system must inform the natural persons exposed to it about its operation and process personal data in accordance with data protection laws (i.e.,GDPR). Exceptions apply for legally authorized law enforcement use under safeguards.

• InnovateAI Corp (ConverseAI): Recalling their earlier decision to avoid inferring emotions for ConverseAI due to Article 5(1f) prohibitions, this reinforces that even if some form were permissible in a different context, transparency would be key.
• TrustFund AI (CreditWise): Unlikely to directly apply to CreditWise’s core function, but if they considered an ancillary feature (e.g., categorizing user feedback sentiment from text, if not based on biometrics inferring emotion), general transparency principles would still be advisable, even if not strictly under this clause.

In Part IV we will discuss General Purpose AI, a cornerstone of the Act.

Cheers!

Disclaimer: The views and opinions expressed in this blog are solely my own and are intended for educational and informational purposes only. They do not constitute legal, financial, or business advice. Readers are encouraged to seek independent professional advice before applying any ideas or suggestions discussed herein. Any reliance you place on the information provided is strictly at your own risk.