OpenAI has published a document that formalizes its practices around safety, transparency, and output traceability to align with the EU AI Act. It’s a policy declaration, not a product announcement: it states what the company does today and what it will do as European regulation advances.

For those building with OpenAI models in regulated contexts (healthcare, finance, public administration), the document is a map of what the provider commits to delivering. Model safety, transparency on how they work, provenance of generated output: these are the pillars that the EU AI Act requires from providers of high-risk systems. If you need to justify your choice of vendor in an impact assessment or audit, knowing that OpenAI puts its commitments in writing gives you a document to lean on.

The move comes days after Anthropic made clear its position on open-weight models, with mandatory testing and export controls on chip shipments. Both frontier labs are now getting ahead of regulators with formal declarations, but focusing on different angles: Anthropic weighs the risks of open weights, OpenAI aligns with the European framework.

What’s still missing: the document is a declaration of intent and current practices, not a third-party verified audit. For those building, the question remains: the vendor declares, but who verifies?

In detail

The EU AI Act came into force in February 2025, but operational deadlines are spread over two years. The first obligations (sanctions for prohibited practices, governance requirements) are already active; requirements for high-risk AI systems apply in full from August 2026. OpenAI’s document arrives exactly in the window when anyone deploying a model in production in Europe needs to demonstrate compliance.

The three pillars OpenAI describes merit a closer look for those not tracking regulation daily:

Safety. OpenAI describes its internal red-teaming, misuse testing, and risk assessments before release. For those building, this means the model arrives with a package of tests already completed, but the responsibility to assess the specific use case remains with whoever deploys it. The EU AI Act isn’t satisfied with the vendor having tested: it wants the deployer to document their own analysis too.

Transparency. OpenAI commits to providing technical documentation, usage instructions, and information on the capabilities and limitations of its models. This is what the EU AI Act calls technical documentation and instructions for use: materials the deployer must have available for authorities.

Provenance. Output traceability is the most interesting pillar and the least defined. OpenAI talks about watermarking (Google’s SynthID is the emerging standard, but OpenAI doesn’t use it yet in text output) and provenance metadata. In practice, today that mostly means C2PA for images. For text, traceability remains an open problem: nobody has a solid technical solution yet.

The document doesn’t detail timelines by model: it doesn’t say which models OpenAI classifies as “high-risk” or when it will release full documentation for each. It’s a statement of direction, not an operational plan with deadlines.

For those coming from the software development world, the gap between this document and a SOC 2 audit is enormous. SOC 2 gives you a report verified by an external auditor. This is a self-declaration by the company. As we reported with the Nvidia and Microsoft alliance for AI security, independent verification tools are still in their infancy. Those building in regulated contexts are right to treat these declarations as a starting point for their own verification, not as a certificate.

The practical lesson for readers: if your project needs to pass a compliance review, download OpenAI’s document, cross-reference it with the specific EU AI Act requirements for your category, and identify where the vendor’s “we commit to” covers the regulator’s “you must demonstrate that.” The gaps are where your work begins.