The AI Act Doesn't Replace ISO 27001. It Proves Why a Mature ISMS Pays Off.

The AI Act's transparency obligations apply from 2 August 2026. If your SaaS company already runs a mature ISO 27001 ISMS, you are further along than you think.

As of today, 2 August 2026, the transparency obligations of the EU AI Act apply.

When the AI Act was introduced, many SaaS companies assumed they were facing yet another standalone compliance project. Another regulation. Another checklist. Another policy to write.

I believe that's the wrong way to look at it.

In fact, I think the AI Act may become the first major European regulation where organisations with a mature ISO 27001 Information Security Management System (ISMS) gain a genuine head start. Not because ISO 27001 is legally required, but because both frameworks are built on the same principles: governance, risk management, accountability, and continuous improvement.

If your organisation already has a mature ISMS, you're likely much further along than you think. The AI Act doesn't replace your ISMS. It builds on it.

The Commission's guidelines on the Article 50 transparency obligations, adopted on 20 July 2026, reinforce exactly that. Rather than introducing entirely new governance concepts, they expect organisations to understand where AI is used, how it interacts with people, what content it generates, and how those decisions are governed. Those are all areas where a mature ISMS already provides a strong foundation.

That doesn't mean you're automatically compliant. AI introduces new responsibilities that ISO 27001 doesn't explicitly address, such as AI literacy, transparency, and AI-specific risk considerations. But instead of starting from a blank page, many organisations already have the right governance structure in place.

The challenge is no longer building an entirely new compliance programme. It's extending the one you already have.

Note: This article is general information, not legal advice.

“The AI Act got delayed” is only half true

You have probably read that Europe pushed the AI Act back. Be careful with that headline. The Digital Omnibus on AI, adopted as Regulation (EU) 2026/1744, changed the application dates for high-risk AI requirements, not the Article 50 transparency timeline.

The relevant dates are:

• 2 December 2027: requirements for standalone high-risk systems classified under Article 6(2) and Annex III.
• 2 August 2028: requirements for high-risk AI embedded in regulated products under Article 6(1) and Annex I.
• 2 August 2026: the Article 50 transparency obligations apply.

There is one limited grace period. Providers of generative AI systems placed on the market before 2 August 2026 have until 2 December 2026 to comply with the marking and detection obligation in Article 50(2). It does not postpone Article 50 as a whole.

A compliance plan that simply says "AI Act postponed until 2027" is therefore misleading. The relevant deadline depends on the AI system, your role, and the specific obligation. For SaaS companies, Article 50 should be assessed now, even when a product is not classified as high-risk. That does not mean every AI feature is subject to every transparency duty; the assessment must be made for each system and use case.

This is why planning around risk works better than planning around a single deadline. Regulatory dates may shift, but your inventory, ownership, classification, and controls should already exist. A management system allows a changing timeline to alter your priorities without changing your foundations.

The biggest misconception

Not quite.

The AI Act distinguishes between providers, deployers, importers, distributors, and other actors in the AI ecosystem. Even if your SaaS platform simply integrates an existing AI model through an API, your organisation may still have responsibilities depending on how AI is used and how your solution is offered to customers.

Worth noting: if you put your own name or trademark on an AI system, or you substantially modify one, you can become the provider yourself. "It's just their model behind our logo" is exactly the situation that shifts obligations towards you.

Calling an AI API does not transfer your compliance obligations to someone else.

Most SaaS companies are not building high-risk AI

The good news is that most SaaS companies are not developing AI systems that fall into the AI Act's high-risk category.

Common examples include:

• AI writing assistants
• Customer support chatbots
• Ticket summarisation
• Meeting transcription
• AI-powered search
• Code generation
• Productivity assistants

These use cases are generally subject to fewer obligations than high-risk systems used in areas such as healthcare, recruitment, education, law enforcement, critical infrastructure, or creditworthiness assessments.

That does not mean there are no responsibilities. Transparency, governance, documentation, and AI literacy are becoming increasingly important for every organisation that develops or deploys AI.

And "probably not high-risk" is a conclusion, not a starting point. The classification is a decision you have to make per AI system and be able to defend. A CV screening feature bolted onto an HR SaaS platform is Annex III, whatever the rest of your product does. The fact that the deadline moved to December 2027 does not make the classification exercise optional today.

This is where an ISMS earns its keep. You already know how to do this: assess per asset, assign a risk owner, document the decision and the reasoning, review it when something changes. Article 6 classification is the same discipline applied to a new asset type. Organisations without that discipline will be re-deriving their answer from scratch every time a customer, an auditor, or a supervisory authority asks.

Transparency is the obligation that is live right now

For many SaaS companies, the first AI Act obligations they encounter have nothing to do with high-risk AI. They are about transparency.

Article 50 covers four situations:

• Direct interaction with people. Providers must design AI systems so that people know they are dealing with a machine, unless it is obvious from the context.
• Synthetic content. Providers of generative AI must mark outputs in a machine-readable format so they are detectable as artificially generated or manipulated.
• Emotion recognition and biometric categorisation. Deployers must inform the people exposed to it.
• Deepfakes and AI-generated text on matters of public interest. Deployers must disclose that the content is artificially generated or manipulated.

That fourth one catches more marketing teams than most SaaS companies expect.

Non-compliance can reach EUR 15 million or 3% of worldwide annual turnover, whichever is higher.

Alongside the guidelines, the AI Office facilitated a Code of Practice on Transparency of AI-generated Content. Signing up is voluntary, but it is currently the clearest available signal of what "state of the art" marking looks like, which matters because Article 50(2) is written against exactly that standard.

Practically, ask yourself:

• Does every user-facing AI feature tell the user it is AI?
• Is that disclosure visible at the moment of interaction, not buried in the terms of service?
• Which of our outputs count as synthetic content, and how are they marked?
• Who owns this in the product roadmap?

This is also where governance becomes visible to your customers. Transparency is not just about legal compliance. It is about building trust.

Where ISO 27001 already gives you a head start

ISO 27001 was never written specifically for AI. Yet many of its requirements map remarkably well to the governance expected under the AI Act.

1. Asset Management

Before you can manage AI risks, you need to know where AI is being used.

Ask yourself:

• Which AI services are in use?
• Which departments use them?
• Which customer data is shared with AI providers?
• Which AI features are customer-facing?
• Which AI models are used in production?
• Which features require transparency notices?
• Which outputs may need to be identified as AI-generated?

If you already maintain a proper asset inventory (A.5.9, A.5.10, A.5.12), extending it to include AI is a natural next step. In practice, the AI inventory is the single artefact everything else depends on. Get it wrong and every downstream classification is guesswork.

2. Supplier Management

Many SaaS companies rely on third-party AI providers.

Do you know:

• where prompts are processed?
• whether prompts or outputs are retained?
• whether customer data is used for model training?
• which subprocessors are involved?
• what contractual guarantees exist?
• what the provider gives you to meet your own transparency duties, such as marking or provenance metadata?

These are supplier management questions (A.5.19 to A.5.22, A.5.23). They are also ISO 27001 questions.

That last bullet is the one people forget. Your ability to comply often depends on what your model provider hands you. That belongs in the contract and in the supplier review, not in a last-minute engineering scramble.

3. Risk Management

AI introduces risks that traditional software often does not.

For example:

• Hallucinations
• Prompt injection
• Data leakage
• Bias
• Model drift
• Overreliance on AI-generated output
• Lack of explainability

These risks should become part of your existing risk assessment process (clauses 6.1.2, 6.1.3 and 8.2), not a separate exercise.

An organisation with one integrated risk register is almost always better positioned than one maintaining separate compliance silos.

4. Policies and Procedures

Many organisations immediately start writing "AI Policies." Sometimes that makes sense. Often, it doesn't. Instead, review the policies you already have.

For example:

• Information Security Policy (A.5.1)
• Acceptable Use Policy (A.5.10)
• Secure Development Policy (A.8.25 to A.8.28)
• Supplier Management Procedure (A.5.19)
• Incident Management Procedure (A.5.24)

Most of these only require targeted updates, such as:

• acceptable use of generative AI;
• approved AI services;
• handling confidential information in prompts;
• human review before publishing AI-generated content;
• documenting AI-assisted decision making where appropriate.

Building on your existing governance is usually far more effective than creating an entirely separate framework.

5. Competence and Awareness

One of the earliest obligations introduced by the AI Act concerns AI literacy. It has applied since February 2025, which makes it the obligation most organisations are already late on.

Employees using AI should understand both its capabilities and its limitations.

For organisations with ISO 27001, this fits naturally into existing competence, awareness, and training programmes (clauses 7.2 and 7.3, control A.6.3).

Instead of creating another mandatory training programme, expand your existing security awareness programme to include responsible AI usage. And keep the attendance records, because "we did the training" is not evidence.

6. Incident Management

Imagine your AI assistant suddenly exposes confidential information. Or starts producing harmful advice. Or behaves unexpectedly after a model update.

Would your incident response process cover this (A.5.24 to A.5.28)?

For organisations with a mature ISMS, the answer is often "yes", with only relatively small adjustments needed to account for AI-specific scenarios. The one worth checking: does a silent upstream model change count as a change in your change management process? For most organisations I see, it doesn't yet.

And if you want the formal version: ISO/IEC 42001

If your customers start asking for certified AI governance, ISO/IEC 42001 is the AI management system standard that sits next to ISO 27001. Same Harmonised Structure, same clause numbering, same logic.

For an organisation with a mature ISMS, that is largely an extension exercise rather than a new build. For an organisation without one, it is a first management system with an AI label on it, which is a much bigger project than it looks.

Compliance is becoming a competitive advantage

The AI Act is not only about avoiding regulatory penalties.

Enterprise customers are increasingly asking questions like:

• Which AI models do you use?
• Is customer data used to train models?
• Can AI features be disabled?
• How do you prevent hallucinations?
• What human oversight exists?
• How are AI-related risks assessed?

Companies that can answer these questions confidently are likely to move through procurement and security reviews much more smoothly. Good governance is becoming a commercial advantage.

Over the past decade, ISO 27001 has evolved from a nice-to-have into an expectation for many SaaS companies serving enterprise customers. I believe AI governance is following the same path.

The organisations that invest in mature governance today won't just be better prepared for future regulation. They'll also be better positioned to earn customer trust tomorrow.

A practical starting checklist

If your SaaS company already uses AI, start with these nine actions:

• 1. Create an inventory of all AI systems, services, and features.
• 2. Determine your role for each one: provider, deployer, or both.
• 3. Identify which customer and business data is processed by AI.
• 4. Check every user-facing AI feature against Article 50 and fix the disclosures first.
• 5. Review contracts and documentation from AI providers.
• 6. Include AI-specific risks in your existing risk assessment.
• 7. Update relevant security policies and procedures.
• 8. Provide AI awareness and literacy training, and keep the records.
• 9. Review whether your incident response and change management processes cover AI-related events, and document governance decisions and responsibilities.

None of these require expensive AI governance software. Most organisations can implement them using the management system they already have.

Good governance scales

The transparency guidance illustrates an important point. The AI Act is moving from high-level legal principles to practical implementation requirements. Organisations are no longer only expected to use AI responsibly. They increasingly need to demonstrate how AI is identified, documented, governed, and communicated to users.

That is exactly where a mature ISO 27001 ISMS provides lasting value.

While new AI-specific controls will continue to emerge, organisations with strong governance, documented processes, supplier oversight, and structured risk management will consistently be better positioned than those treating every new regulation as a separate compliance exercise.

GDPR challenged organisations to improve privacy. NIS2 raises the cybersecurity baseline. The AI Act rewards organisations that have already invested in mature governance.

Need help preparing your SaaS organisation?

Whether you're implementing ISO 27001, preparing for NIS2, or establishing practical AI governance, the objective is the same: helping your organisation stay in control.

At Coding Mammoth, we help SaaS companies build governance that is practical, proportionate, and designed to support growth rather than slow it down.