AI Act Compliance for OpenAI-Powered SaaS

The myth: “OpenAI handles compliance”

If your SaaS calls the OpenAI API, you still have a role — often as a provider of an AI system (your product) and/or a deployer of a GPAI model. OpenAI’s terms, model cards, and DPA help, but they do not write your disclosure, oversight SOP, or enterprise evidence pack.

Start with role, not with the model name

Ask:

1. Who places your product on the market?
2. Who determines the intended purpose of the AI feature?
3. Is the model GPAI used as a component inside your system?
4. Do outputs affect people in the EU?

Provider vs deployer vs GPAI provider duties differ. See also: Provider vs deployer vs GPAI provider.

What OpenAI-powered SaaS usually still owns

Near-term (transparency)

• Art. 50 disclosure when users interact with AI or see AI content — from 2 August 2026 where applicable
• Clear UX copy: “You’re chatting with an AI assistant…”

Always useful for diligence

• Model / vendor inventory (model, version, data sent)
• Data-flow description
• Prompt / tooling boundaries (what the model can do in your product)
• Human oversight path for high-impact actions

If Annex III may apply

• Treat high-risk documentation as prepare now toward 2 December 2027
• Do not assume OpenAI “covers” Annex IV or registration for your system

Vendor diligence checklist (minimum)

• DPA in place
• Subprocessor list reviewed
• What customer data is sent to the API
• Retention / training opt-out settings understood
• Incident / outage contact path

Use the AI vendor inventory template.

Recommended workflow

1. Map features that call OpenAI.
2. Write intended purpose per feature.
3. Draft disclosure + oversight.
4. Generate a free readiness brief.
5. Send brief + inventory to counsel before enterprise security review.

Not legal advice. API usage does not equal automatic compliance.