EU AI Act Requirements: Complete Breakdown of Obligations, Controls, and Compliance Steps

You might already know the EU AI Act applies to you; you know there are obligations, but you don’t know what you actually have to do. The Act lists Articles. Your auditor asks for evidence. Your engineering team asks for specifications. Extracting exact actionables from the legal text is not easy, and that’s where teams often stall.

I want to help you address this challenge. Article by Article, I will take you through what each requirement asks of you, what you need to document, what you need to build into the product, and what you need to keep doing after launch. Along the way, I will also cover how your existing SOC 2 or ISO 27001 compliance workflows map to AI Act obligations, what the harmonized standards will not cover, and how to use the GPAI Code of Practice when negotiating with foundation model vendors.

EU AI Act risk-based framework

The Act sorts AI systems into four tiers. The requirements you owe depend on which tier each of your systems lands in. This section maps each tier to the specific requirements it triggers, so you can jump directly to the relevant deep dives below.

Most teams that run the classification exercise honestly discover that their AI is minimal-risk and have no further obligations to operationalize it. The teams that land in high-risk are the ones that need the rest of this article.

Risk tier	What it triggers
Prohibited (Article 5)	Compliance cannot be achieved. The system cannot be deployed. The Omnibus added a December 2026 prohibition on AI generating CSAM or non-consensual intimate imagery.
High-risk	The full set: Articles 9 through 15, Article 17 QMS, conformity assessment, CE marking, EU database registration, post-market monitoring, incident reporting.
Limited-risk	Article 50 transparency obligations only. Chatbots must disclose AI. Synthetic content must be machine-readable. Deepfakes must be labeled.
Minimal-risk	No specific obligations under the Act, though GDPR and sector-specific law still apply.

For the conceptual breakdown of each tier with examples, and for the Article 6(3) escape-clause analysis, see the compliance guide.

Requirements for different stakeholders

Your obligations flow in two ways: The role you play in the AI value chain and the risk classification of each system. Get either wrong and the rest of your program is built on a faulty foundation. 

Role	Articles that apply	Core obligations
Provider (of high-risk AI)	Articles 9 through 15, 17, 43, 47, 48, 49, 72, 73	Risk management, data governance, technical documentation, logging, transparency to deployers, human oversight, accuracy and robustness, QMS, conformity assessment, CE marking, EU database registration, post-market monitoring, incident reporting.
Deployer (of high-risk AI)	Article 26, parts of Articles 14, 27	Use according to instructions, human oversight in operation, log retention, transparency where applicable, Fundamental Rights Impact Assessment for public bodies and certain private entities.
Importer	Article 23	Verify provider met conformity obligations, technical documentation exists, CE marking is affixed, instructions for use are provided.
Distributor	Article 24	Verify CE marking and accompanying documents. Take corrective action if there is reason to believe the system is non-compliant.
Downstream provider	Inherits provider obligations	If you substantially modify a high-risk AI system or place it on the market under your own name, you become the provider and inherit the full Article 9 through 15 and Article 17 obligation set.

Watch the full Understanding ISO 42001 & EU AI Act walkthrough with Babl AI →

The downstream-provider rule is the one SaaS teams most need to review carefully. Fine-tuning a foundation model for your product, retraining on your own data, or shipping the integrated AI under your own brand can push you from deployer obligations to provider obligations. Our EU AI Act compliance SaaS archetypes section walks through this with three concrete patterns.

When the EU AI Act requirements apply

Obligation	Original date	Date after Omnibus
Prohibited practices (Article 5)	February 2, 2025	February 2, 2025 (unchanged)
AI literacy (Article 4)	February 2, 2025	February 2, 2025 (unchanged)
GPAI model obligations	August 2, 2025	August 2, 2025 (unchanged)
New CSAM/nudifier prohibition	n/a	December 2, 2026
Article 50(2) watermarking (new systems)	August 2, 2026	August 2, 2026 (unchanged)
Article 50(2) watermarking (in-market systems)	August 2, 2026	December 2, 2026
Annex III high-risk obligations	August 2, 2026	December 2, 2027
Annex I high-risk obligations	August 2, 2027	August 2, 2028
GPAI enforcement powers	August 2, 2026	August 2, 2026 (unchanged)

How existing certifications map to AI Act requirements

If you already run SOC 2, ISO 27001, or ISO 42001, you are not starting EU AI Act compliance from zero. You might discover that the controls you already implemented cover 40-60% of the AI Act obligations. The operational question is: which Articles require new evidence, and which can be satisfied with the controls you already have in place?

The table below covers the overlap. Use it before building anything new, so you do not rebuild controls you already have while leaving the genuinely AI-specific gaps unaddressed.

Existing certification	Covers parts of	Does not cover
SOC 2	Article 15 cybersecurity (access controls, vulnerability management, incident response), parts of Article 17 QMS (change management, monitoring), parts of Article 12 (logging infrastructure for security events)	AI-specific risk management (Article 9), data governance for training data (Article 10), human oversight design (Article 14), Annex IV technical documentation (Article 11), conformity assessment (Article 43)
ISO 27001	The same security controls as SOC 2, plus ISMS scaffolding that maps to parts of Article 17, parts of Article 15 (information security risk treatment)	All AI-specific obligations. Risk management for the AI system itself, data governance, transparency, human oversight, technical documentation, conformity assessment
ISO 42001	Substantial parts of Article 17 QMS, parts of Article 9 (AI risk management framework), parts of Article 10 (data governance), parts of Article 14 (oversight principles)	Specific Annex IV technical documentation contents, conformity assessment under Article 43, EU declaration of conformity, CE marking, EU database registration, post-market monitoring specifics under Article 72
GDPR	Parts of Article 10 (where AI training data is personal data), parts of Article 13 (transparency to data subjects), parts of Article 27 (impact assessment foundations)	Most AI-specific obligations. GDPR is rights-based; the AI Act is product-safety-based. The two coexist but do not substitute for each other.
NIST AI RMF	Conceptual scaffolding for Article 9 risk management. The Govern, Map, Measure, Manage functions align with the Article 9 cycle at the principles level.	Voluntary US framework with no direct legal mapping to AI Act conformity. Useful as scaffolding, not as evidence.

High-risk AI requirements (core compliance obligations)

If your AI system is classified as high-risk, obligations in Articles 9 through 15, plus Article 17, will apply. Each is a separate requirement with its own evidence trail.

Article 9 is the core. It asks you to maintain a live, continuously updated picture of what could go wrong when your AI operates as intended. Everything else either feeds that picture or acts on it. 

AI risk management requirements (Article 9)

Article 9 calls for a risk management system that runs continuously throughout the lifecycle of the AI system. Not a one-time risk assessment filed at launch. Not a document in SharePoint. A live process that keeps running as long as the system is in use.

The process has four required steps: 

1. Identify known and reasonably foreseeable risks to health, safety, and fundamental rights
2. Estimate and evaluate those risks
3. Adopt mitigations
4. Test that the mitigations work under conditions representative of real use. 

Then do it again. Every time you retrain the model, modify the architecture, expand the use case, or change the deployment context, the cycle runs.

What regulators expect to see when they investigate is not just the current risk assessment. They want the iteration history: the methodology, the risks identified at each stage, the mitigations adopted, and the documented link between each identified risk and the specific control or design choice that addresses it. A risk register with no traceability to mitigations will not hold up.

The teams that handle Article 9 well treat it as part of the model release process, not as a separate quarterly review.

Other high-risk obligations

The remaining high-risk Articles operationalize different parts of the Article 9 risk assessment. Article 10 governs the data going in. Article 14 governs human control. Article 15 governs performance and security. Article 17 is the management system tying it all together. Each requires a distinct evidence trail.

1. Data and data governance (Article 10)

Article 10 governs what goes into your system. Training, validation, and testing datasets must be relevant, sufficiently representative for the intended purpose, and free of errors and complete to the extent reasonably practicable.

The documentation requirement covers the entire data pipeline: Design choices, collection methodology and origin, preparation operations (annotation, labeling, cleaning, enrichment, aggregation), assumptions made at each stage, assessment of data availability and suitability, examination for bias, and identification of gaps.

The May 2026 Digital Omnibus extended one provision here. Providers and deployers of non-high-risk systems can now process special categories of personal data for bias detection and correction, subject to a strict-necessity standard. Before the Omnibus, this exception was limited to high-risk systems.

2. Human oversight (Article 14)

Article 14 requires that high-risk AI systems be designed so that natural persons can effectively oversee them during use. The word ‘designed’ is doing a lot of work here. This is a product requirement, not a policy requirement. The oversight capability has to be built into the system before it ships.

The practical demands: human overseers must be able to fully understand the system’s capabilities and limitations, remain aware of automation bias, correctly interpret output, decide not to use or override it, and intervene or interrupt via a stop button or equivalent mechanism.

For remote biometric identification systems specifically, Article 14 requires that decisions based on AI output be verified and confirmed by at least two natural persons before any consequential action is taken.

If you are building a high-risk AI feature and plan to add human oversight in a later product iteration, you are building it wrong. Oversight has to be part of the initial spec.

3. Accuracy, robustness, and cybersecurity (Article 15)

Article 15 sets the performance and security floor. High-risk AI systems must achieve appropriate levels of accuracy, robustness, and cybersecurity throughout their lifecycle. Accuracy levels and the metrics used to measure them must be declared in the instructions for use.

Robustness refers to a system’s resilience against errors, faults, and inconsistencies, including attempts to alter its behavior. The recitals name the specific attack vectors: data poisoning, model poisoning, model evasion, confidentiality attacks, and adversarial examples.

EEAT: These aren’t theoretical threats anymore

Sprinto’s 2026 Pulse Check report found that over 30% of U.S. organizations have already experienced a major AI-related security incident in the past 12 months, with shadow AI usage, data leakage / model inversion, API abuse, and data poisoning as the most common patterns. Article 15’s robustness clause exists because these attack surfaces are now operational realities, not future risks.

If your high-risk AI system is also a product with digital elements under the EU Cyber Resilience Act (CRA), then Article 15 and the CRA overlap substantially. You should map that overlap early. It affects which notified body (if any) you need and how you structure technical documentation.

4. Quality management system (Article 17)

Article 17 requires providers of high-risk AI systems to establish a quality management system (QMS) before market placement and to keep it operational throughout the system’s lifecycle.

The QMS must cover a regulatory compliance strategy, design and development procedures, testing and verification procedures, technical specifications and standards applied, data management systems, the Article 9 risk management system, post-market monitoring procedures, incident reporting procedures per Article 73, and an accountability framework.

ISO/IEC 42001 is a useful governance scaffold, and companies with existing 42001 certification have a head start on Article 17. But 42001 alone does not satisfy conformity. The EU AI Office has signaled that existing ISO quality management standards do not fully reflect the EU’s approach. The harmonized European standard prEN 18286, being drafted by CEN-CENELEC JTC 21 and expected to be published in late 2026, will eventually provide the presumption of conformity. Until then, build your QMS to the Article 17 text.

5. Conformity assessment, CE marking, and EU database registration

Before a high-risk AI system ships, you must take four steps. First, conformity assessment, EU declaration of conformity, and CE marking. Then, before the system reaches the market, it should be registered in the EU database.

• Conformity assessment: This involves verifying that the system satisfies Articles 9 through 15 and Article 17. Two paths exist. Internal control (Annex VI) applies to most Annex III systems, where the provider conducts the assessment in-house with no third-party involvement. Third-party assessment by a notified body (Annex VII) applies to remote biometric identification systems, AI safety components in regulated products, and cases where the provider has not applied harmonized standards.

Internal control does not mean less work. It means you are the certifier. Your documentation has to hold up under regulatory scrutiny without a notified body’s stamp.

• EU declaration of conformity (Article 47): Once the assessment is complete, the provider prepares a declaration stating that the system meets all applicable requirements. It is a legal document, not a formality.
• CE marking (Article 48): The CE mark is the European Union’s standard symbol of regulatory conformity, visible on products from toys to medical devices to industrial machinery sold in the EU. For high-risk AI systems, affixing the CE mark is a legal declaration that the provider has completed the conformity assessment and the system meets the Act’s requirements. CE marking is affixed after the Article 47 declaration of conformity is drawn up. Affixing it before completing the conformity assessment is a violation.
• EU database registration (Article 49): Before placing the system on the market, providers register the system in the EU’s public AI database. The Omnibus reinstated this requirement even for systems claiming the Article 6(3) escape clause. The reason is traceability.

AI Act technical documentation requirements

Technical documentation under the Act covers two distinct things that are easy to conflate. The Annex IV file describes the system. Article 12 event logging captures what the system does while it is running. One is built before market placement. The other accumulates after launch. Both are required.

1. The Annex IV technical documentation file

Annex IV specifies nine sections. This is the file a regulator asks for first. Build it from the start, version-controlled alongside the system.

Section 1, general description: Name, version, intended purpose, the providers and components the system was built on (including third-party models), hardware it runs on, and instructions for use.

Section 2, detailed description of system elements: Development methods, design specifications, architecture, computational resources, training data requirements, and the reasoning behind each major design choice.

Section 3, monitoring, functioning, and control: How the system is monitored in operation, its functioning parameters, and the controls available to operators and deployers. Your Article 14 human oversight mechanisms are documented here.

Section 4, performance metrics: The metrics used to assess accuracy, robustness, and bias, with justification for why those metrics are appropriate for the intended purpose.

Section 5, risk management documentation: The output of your Article 9 process, the iterations, the identified risks, and the specific mitigations deployed.

Section 6, lifecycle changes: Updated every time the system is modified, retrained, or its use case expands.

Section 7, standards and specifications applied: The harmonized standards applied, with specific provision references. Where no harmonized standard was applied, a description of the alternative solution used to demonstrate conformity.

Section 8, EU declaration of conformity: A copy of the Article 47 declaration.

Section 9, post-market monitoring plan: The monitoring methodology, metrics and thresholds that trigger corrective action, and incident reporting procedures. This section has to exist before the system ships.

You cannot go to court and argue that incomplete documentation was acceptable because the harmonized standards were not published. Standards are a voluntary compliance pathway. Their absence does not stop the Act from applying.

2. Automatic event logs (Article 12)

Article 12 requires high-risk AI systems to be designed with automatic logging that records events relevant to risk identification and substantial modifications throughout their operational lifetimes. Logs must enable post-market monitoring, support risk identification, and let deployers monitor the system’s operation.

The minimum expectation: the input data used for each decision, the reference databases queried, the natural persons involved in verifying the output, where applicable, and the time period for each use.

Retention is at least six months. Financial services and healthcare typically require longer retention periods; check your sector’s obligations before setting retention windows.

Build the logging layer before you build the features. Retrofitting structured event logging after launch is expensive, creates historical gaps that become clear under audit scrutiny, and requires architectural changes that product teams resist making after the fact.

EU AI Act transparency requirements

Transparency obligations under the Act fall into two distinct categories that are often treated as a single category. Article 13 governs what providers must tell deployers. Article 50 governs what the system must tell users. The two have different owners and different mechanics.

1. Article 13, transparency to deployers

Article 13 requires providers to accompany high-risk AI systems with instructions for use that are concise, complete, correct, and clear. They must specify the provider’s identity and contact details; the system’s characteristics, capabilities, and limitations (including accuracy levels it was tested against and known foreseeable circumstances that may lead to risks); the human oversight measures the deployer is responsible for; expected operational lifetime and maintenance; and a description of the logging mechanisms.

Instructions for use are a legal document. Write them with the assumption that a deployer’s legal team and a regulator will both read them.

2. Article 50, transparency to users

Article 50 covers four obligations, each triggered by a different kind of AI system.

1. Chatbots and AI systems that interact with natural persons must inform users that they are interacting with an AI system, unless it is obvious from context. Already in force for limited-risk systems.
2. AI-generated synthetic content must be marked as artificially generated using machine-readable methods, such as watermarks, metadata, or cryptographic marks. The Code of Practice on Marking and Labeling of AI-Generated Content (second draft published March 5, 2026) is the operational specification. Watermarking across different content modalities requires distinct technical approaches, and the Code is still in the process of iterating.
3. Deepfakes must be labeled as artificially generated or manipulated, in addition to being marked machine-readable.
4. AI-generated text published for public interest must disclose its artificial origin. Limited exceptions apply.

Timeline: The machine-readable marking required under Article 50(2) applies from August 2, 2026, for new generative AI systems. Providers with in-market systems by that date get a transitional period until December 2, 2026.

The new Article 5 prohibition on AI-generated CSAM or non-consensual intimate imagery takes effect on December 2, 2026. It applies to purpose-built systems and to providers of general-purpose generative AI who fail to put adequate safeguards in place.

Post-market monitoring and incident reporting

Once a high-risk AI system is made available in the market, the obligations shift rather than end. Articles 72 and 73 govern the monitoring loop and the incident reporting pipeline, which run as long as the system is in service. Most AI programs underestimate this. The build phase gets all the attention, while the monitoring phase is inherited by whoever is responsible for post-shipping activities. 

a. Article 72, post-market monitoring

Article 72 requires providers to establish, document, and actively operate a post-market monitoring system proportionate to the system’s risks. It must collect, document, and analyze performance data throughout the operational lifecycle, enabling the provider to evaluate whether the system remains compliant.

The monitoring plan, documented in Annex IV Section 9 before the system ships, must specify collection and analysis methods, the metrics and thresholds that constitute an anomaly, and the criteria that trigger corrective action.

b. Article 73, serious incident reporting

Article 73 sets the timeline obligations for reporting serious incidents to the relevant market surveillance authority. Three categories, three timelines:

1. Standard serious incidents: Report no later than 15 days after awareness.
2. Incidents involving infringement of fundamental rights obligations: Report within 72 hours.
3. Widespread infringement or incidents resulting in death: Report immediately, no later than 2 days.

These timelines require your incident detection and classification process to be set up before you need it. The 15-day window is shorter than it looks once you account for internal escalation, legal review, and the mechanics of contacting the relevant authority. Build the process. Then put it in a drawer you can open fast.

The unstandardized zone: What harmonized standards will not cover

The harmonized European standards under development through CEN-CENELEC JTC 21 will eventually cover Articles 8 through 15, the substantive high-risk obligations. They will give you a presumption of conformity for those Articles once published. They will not cover everything, and most teams misjudge this.

If you treat the harmonized standards as the eventual answer to every operational question, you are likely going to be surprised. A meaningful portion of how you prepare for the Act will continue to be guided by the legal text, the Commission’s evolving guidelines, and your own legal judgment, even after the standards are published.

What the standards will cover (eventually):

• Article 9 risk management methodology
• Article 10 data governance practices
• Article 11 technical documentation structure
• Article 12 logging requirements
• Article 13 transparency to deployers
• Article 14 human oversight mechanisms
• Article 15 accuracy, robustness, and cybersecurity testing
• Article 17 QMS (via prEN 18286)

What the standards will not cover:

• Risk classification under Article 6 and Annex III: Determining whether your system is high-risk is a legal question, not a technical one. Standards cannot tell you whether your hiring tool falls under Annex III; that is worked out from the legal text and the Commission’s guidelines.
• The Article 6(3) escape clause analysis: If you are claiming your system is not high-risk despite falling under an Annex III category, the reasoning behind that claim has to be a legal judgment. No standard helps you make it.
• Article 4 AI literacy: A ‘sufficient level of AI literacy’ is interpretive. The Commission maintains a living repository of practices, but there is no harmonized standard for what AI literacy training should include.
• Article 50 transparency disclosures: The Code of Practice on Marking and Labeling is being drafted, but it is a code of practice, not a harmonized standard. Watermarking implementation is also technically variable by content modality.
• Article 5 prohibited practices: The list of banned uses is in the legal text and grows by amendment. Standards do not translate ‘banned’ into operational guidance. You are either doing the prohibited thing, or you are not.

Using the GPAI Code of Practice as a vendor specification

If you are a SaaS team building on OpenAI, Anthropic, Google, or Mistral foundation models, the GPAI Code of Practice is the most useful operational document in the Act’s ecosystem. It exists because downstream providers (you) need specific information and guarantees from upstream GPAI providers to meet your own obligations. Most teams have not realized they can use it as procurement leverage.

The Code was published on July 10, 2025, and formally approved by the Commission and the AI Board on August 1, 2025. It is organized into three chapters: Transparency, Copyright, and Safety and Security. 

The first two map to Article 53 obligations that apply to all GPAI providers. The third covers Article 55 obligations that apply only to providers of GPAI models with systemic risk (typically those trained with more than 10²⁵ FLOPs of compute).

OpenAI, Anthropic, and Google are signatories. Adherence is voluntary, but signatories get reduced enforcement scrutiny, and adherence is a relevant factor in setting any fines.

What this means in practice for your vendor negotiations:

• You can require Code-aligned documentation from your model provider: The Code specifies what providers should make available to downstream integrators: model cards, training data summaries, evaluation reports, and documentation that lets you implement the model safely. Explicitly ask for these in your contracts.
• Code commitments can be attested to: When negotiating renewals or new contracts with foundation model providers, ask them to confirm in writing which specific Code commitments they are meeting and provide the supporting artifacts.
• Non-signatory vendors are a procurement signal: If a foundation model provider is not a Code signatory, that is worth flagging during vendor due diligence. It does not disqualify them, but it means your documentation burden as a downstream provider will be heavier, and your evidence trail will be more fragile.
• The Code feeds your Annex IV documentation: When you write Annex IV Section 1 (general description) and Section 2 (system elements), you will reference the GPAI model on which your system was built. The Code-required artifacts from your model provider populate those references. Without them, your Annex IV file has gaps that regulators will notice.

What changed in May 2026: The Digital Omnibus quick recap

The European Commission, the EU’s executive body, proposed the Digital Omnibus on AI after it became clear that the harmonized standards businesses needed to meet the August 2026 obligations would not be ready in time. 

The proposal then moved into trilogue negotiations, the closed-door process where the Commission, the European Parliament, and the Council of the EU (representing member state governments) work out a final compromise text. 

The first round ended without agreement, but the three institutions reconvened and reached a provisional agreement on May 7, 2026. It included headline changes such as:

• Annex III high-risk obligations postponed to December 2, 2027, from the original August 2, 2026.
• Annex I high-risk obligations (AI embedded in regulated products) have been postponed from August 2, 2027, to August 2, 2028.
• Article 50(2) watermarking remains on August 2, 2026, for new generative AI systems. Providers with systems already on the market by that date get a transitional period until December 2, 2026.
• New Article 5 prohibition for AI systems generating CSAM or non-consensual intimate imagery (nudifier tools). Applies from December 2, 2026.
• SME relief extended to small mid-cap enterprises (SMCs).
• The Machinery Regulation carved out of the direct AI Act applicability. MDR, IVDR, and the Radio Equipment Directive were not moved.
• EU database registration reinstated for high-risk systems claiming the Article 6(3) escape clause.

What did not change: Prohibited practices, Article 4 AI literacy, GPAI obligations, and the substantive requirements for high-risk systems themselves.

This is a provisional political agreement. It still needs formal endorsement by Council and Parliament, then legal-linguistic revision, then publication in the Official Journal. Both institutions have committed to adoption before August 2, 2026. Until then, the original AI Act dates remain legally in force, but the practical planning baseline is the new dates.

Step-by-step guide to meeting EU AI Act requirements

Here’s how you can meet the EU AI Act requirements by category.

1. Build your AI inventory. Find every AI system in your environment, including shadow AI adopted by employees informally.
2. Classify risk for each system. Use the risk-based framework table above. Document Article 6(3) reasoning where applicable.
3. Map your role per system. Use the stakeholder table above. Your obligations flow from this.
4. Implement required controls. For high-risk systems, work through Articles 9, 10, 12, 14, 15, and 17 using the sections above.
5. Build documentation and evidence. Annex IV nine sections, version-controlled alongside the system.
6. Complete conformity assessment and registration. Articles 43, 47, 48, 49 in sequence.
7. Establish monitoring and reporting. Articles 72 and 73, operationalized before launch.

Every Article in this Act is a continuous obligation, not a one-time project. Article 9 risk management runs on every model release. Article 12 logs accumulate every day. Article 72 monitoring runs as long as the system is in service.

Documentation drifts the moment the system changes. The teams that handle this effectively typically don’t run compliance as a quarterly exercise; they treat it as live infrastructure. That is what Sprinto is built for.

How Sprinto helps you meet EU AI Act requirements

Sprinto is an Autonomous Trust Platform that maps the controls you already operate (SOC 2, ISO 27001, ISO 42001, GDPR, NIST AI RMF) to specific AI Act Articles, so the 40-60% overlap most teams have becomes operational evidence rather than evidence you build twice. When new evidence is required, the platform tells you which Articles are short and what the gap is. 

Three things matter most for the Articles in this act:

1. Shadow AI detection feeds Article 11 documentation and Article 4 literacy: Your Annex IV file cannot describe systems you do not know exist. Sprinto’s live registry surfaces every AI tool in your environment, including those product or marketing teams brought in informally, so your inventory is real rather than aspirational.
2. Cross-framework mapping turns Articles 9 through 15 and 17 into evidence you already have: SOC 2 controls that satisfy parts of Article 15. ISO 42001 controls that satisfy parts of Article 17. The platform connects them automatically. The remaining tasks are the AI-specific delta, not the entire program.
3. Continuous monitoring is Article 72: The post-market obligation is where most compliance programs lose ground because the team that built the system has moved on. Sprinto’s monitoring loop flags drift in real time: when a control fails, when evidence ages out, when a vendor adds an AI feature you have not assessed. The Article 72 plan that lives in your Annex IV file becomes the system that actually runs.

Schedule a demo with our team to see what the EU AI Act looks like for your business: which Articles apply to your systems, which controls you already have in place, and what the next 90 days look like.

FAQs