The EU Can Enforce Model Duties From 2 August. Your Vendor File Should Show It.

The European Commission gains enforcement powers over general-purpose AI model provider obligations from 2 August 2026. The obligations themselves have applied since 2 August 2025, so this is an enforcement milestone, not a new rulebook arriving overnight. From that date, the Commission can investigate compliance and impose penalties where the AI Act permits it (European Commission).

For an Australian bank, insurer or superannuation team, the practical response is not to stamp every model file “EU compliant”. It is to determine the organisation's role and EU connection, identify the exact model and version in use, then collect the evidence needed to support that position. A vendor name and a link to a policy page are not enough.

The final AI Omnibus has moved specified high-risk system dates to 2 December 2027 and 2 August 2028. It did not move this general-purpose AI enforcement milestone (European Commission, Regulation (EU) 2026/1744). Treat the two timelines as separate clocks.

What actually changes on 2 August?

The core duties depend on the provider and the model. Subject to conditional exemptions for qualifying free and open-source models, providers of general-purpose AI models must maintain technical documentation for authorities, give downstream providers information needed to understand and integrate the model, maintain a policy for complying with Union copyright law, and publish a sufficiently detailed summary of training content. The copyright-policy and public training-summary duties still apply to qualifying open-source models, while systemic-risk models do not receive those exemptions. A provider established outside the EU may also need an authorised representative when it places a model on the Union market (European Commission FAQ).

Models classified as presenting systemic risk attract additional duties. Those include model evaluations and adversarial testing, systemic-risk assessment and mitigation, serious-incident reporting, and an adequate level of cybersecurity protection. Those requirements do not turn every enterprise use of a large model into a systemic-risk deployment. They sit with the relevant provider and model classification (European Commission FAQ).

The voluntary General-Purpose AI Code of Practice is one route by which a provider can demonstrate compliance. It is not the only route and it is not mandatory. If a supplier does not rely on the Code, your question should be what alternative adequate means it uses and what downstream evidence it will provide.

There is also a transition date that procurement records should preserve. Providers of models placed on the market before 2 August 2025 have until 2 August 2027 to comply with the provider obligations. A receipt that records only the vendor, but not the model version and original market date, cannot distinguish a current evidence gap from an applicable transition (European Commission).

The clocks worth writing into the vendor file:

This does not mean an Australian customer is entitled to the provider's complete technical file. Some documentation is for regulators. The useful procurement question is narrower: what information is available to a downstream provider or deployer, what public evidence exists, what assurance can be shared under contract, and what remains unavailable?

Does this make an Australian buyer an EU-regulated provider?

No, not merely because it pays for or uses a European-facing model. The Act's territorial scope includes providers placing AI systems or general-purpose AI models on the Union market, deployers established or located in the Union, and third-country providers or deployers where an AI system's output is used in the Union. It also separately covers importers and distributors of AI systems (Regulation (EU) 2024/1689, Article 2). The Commission's guidance distinguishes roles, including a model provider and a bank acting as a deployer (European Commission).

That distinction matters. An Australian group might have an EU branch using an assistant, integrate a model into a service offered in the EU, or place a model or AI system on the Union market under its own name. Those facts can produce different role and scope questions. A purely Australian internal workflow does not acquire an EU legal status simply because its supplier operates globally; at home it remains governed by existing Australian law, an approach we mapped in Australia's decision not to pass an AI Act.

Start with a provisional role map, then have legal or compliance specialists confirm it. Do not ask an AI assistant to make the legal conclusion.

Use this prompt to organise an EU exposure review. A legal or compliance professional must verify the role, territorial connection and current law before the result enters the vendor file.

You are assisting with evidence organisation, not giving legal advice.

For the AI use case below, prepare a provisional role and EU exposure map.

Inputs:
- organisation: [ORGANISATION_NAME]
- business unit: [BUSINESS_UNIT]
- use case: [USE_CASE]
- model and version: [MODEL_ID]
- supplier and contracting entity: [SUPPLIER]
- users and operating locations: [LOCATIONS]
- customers or affected people in the EU: [EU_CONNECTION]
- whether the model is modified, fine-tuned, rebranded or distributed: [CHANGES]
- current human review point: [HUMAN_REVIEW]

Return:
1. facts supplied
2. facts missing
3. possible roles to test, without selecting a final legal role
4. possible EU connections to test
5. evidence needed for each open question
6. questions for legal, privacy, procurement and model-risk owners
7. a clear list of conclusions that cannot be made from the information supplied

Do not invent facts, legal duties, dates, article numbers or conclusions.

Fictional worked example: [ORGANISATIONNAME] operates an internal policy-drafting assistant for [EUBRANCH]. Staff request summaries of approved internal documents, then [HUMANREVIEWERROLE] checks every draft before use. The team records itself provisionally as a deployer, flags the EU workplace connection for legal confirmation, and records [MODELID] separately from the supplier's brand. It does not claim provider compliance on the supplier's behalf.

That small discipline prevents a common category error. The receipt does not say “the AI Act applies” as a single yes-or-no field. It records the relevant entity, geography, role, use, model and date, with the final legal assessment linked beside them.

What evidence should your vendor file contain?

Use a model evidence receipt. It is an enforcement-to-contract map, not another due-diligence questionnaire. Each row links a relevant provider duty or supplier claim to the exact artefact you received, its owner, its model coverage and the event that requires a refresh.

A useful receipt contains:

1. Identity and scope. Supplier, contracting entity, model ID, version, release date, hosting surface, operating regions, approved use case and provisional customer role.
2. Compliance route. Whether the provider says it follows the voluntary Code of Practice or uses another route, plus the dated source for that statement.
3. Downstream information. Integration documentation, intended capabilities, material limitations, relevant input and output characteristics, and the version each document covers.
4. Provider assurance and public evidence. Any supplier assurance about its copyright compliance policy, plus the mandatory public training-content summary, with the retrieval date. Record absence as a gap, not as proof of non-compliance.
5. Systemic-risk evidence where applicable. Available summaries or contractual assurance about evaluation, systemic-risk controls, incident handling and cybersecurity. Do not copy a generic systemic-risk field onto a model without confirming the classification.
6. Change control. Named evidence owner, last review date, contractual notification terms, replacement model process and refresh triggers for a version change, material documentation update, incident or regulatory change.
7. Exceptions. Missing evidence, supplier restrictions, compensating controls, expiry date and the human who accepted the residual risk.

The new technique is the refresh trigger. A static PDF can age quietly. A receipt tied to the model ID and contract turns an updated model, changed compliance route or withdrawn document into a review event. The version churn is not hypothetical: every model you rely on has a published retirement date, and the model named in a receipt will eventually be replaced under it.

Use this prompt to test a draft receipt for gaps. Procurement, model-risk and legal owners must open the original sources and decide whether each gap is acceptable.

Review the model evidence receipt below as an evidence-quality assistant.

For each row:
- identify the factual claim
- name the cited artefact and model version
- mark the evidence as direct, indirect, stale, missing or unclear
- separate provider obligations from customer controls
- identify any statement that overclaims EU AI Act coverage
- propose the smallest follow-up question needed
- propose a refresh trigger

Then produce:
1. a gap register
2. a list of claims supported by primary evidence
3. a list requiring legal or compliance review
4. a list requiring supplier confirmation

Do not infer compliance from a certification logo, vendor name or unsigned summary.

RECEIPT:
[PASTE REDACTED MODEL EVIDENCE RECEIPT]

For Australian financial-services teams, the receipt should sit beside the existing third-party, privacy, information-security and model-change records. For an APRA-regulated entity, it may support CPS 230 assessment and monitoring where the AI arrangement is material, a discipline we covered when the CPS 230 contract deadline caught up with AI vendors, and CPS 234 assessment of a third party's information-security capability where that party manages information assets, the ground covered in what CPS 234 due diligence on AI vendors requires (APRA CPS 230, APRA CPS 234). It does not satisfy either standard, and not every AI supplier is a material service provider.

Do this Monday

1. Find the EU-connected workflows. Search the AI use-case register for EU staff, branches, customers, services, hosting or distribution. Record the connection without making a legal conclusion.
2. Assign provisional roles. For each relevant entity and use case, record possible general-purpose AI model-provider and AI-system provider, deployer, importer or distributor roles. Give legal or compliance the facts and open questions to confirm.
3. Create one model evidence receipt. Pilot it on the highest-impact EU-connected workflow. Include the exact model ID, surface, version, provider evidence, transition date and current gaps.
4. Send a version-specific supplier request. Ask which compliance route applies, which downstream documents cover the model, what public evidence is current, and what assurance is available for any systemic-risk obligations.
5. Install refresh triggers. Require review when the served model, hosting surface, compliance route, material documentation or incident position changes. Keep a named human owner for accepting gaps and approving continued use.

The immediate aim is not a perfect cross-border register. It is one defensible chain from use case to role, model, source and decision. Once that chain works, apply it to the remaining EU-connected workflows.

Bottom line

The 2 August milestone changes the enforcement posture, not the date on which general-purpose AI provider duties first applied. Australian buyers should resist both complacency and blanket claims of EU coverage. Build a model evidence receipt that distinguishes supplier duties, customer controls and unresolved role questions. Human legal, compliance, procurement and model-risk owners should decide what the evidence means and whether the use can continue.

This article is general information and education only. It is not legal, compliance, financial or professional advice. Obligations vary by organisation and circumstance. Verify current requirements against the primary sources cited and seek advice specific to your situation.

References

1. European Commission, “Guidelines for providers of general-purpose AI models”: https://digital-strategy.ec.europa.eu/en/policies/guidelines-gpai-providers
2. European Commission, “Guidelines on obligations for general-purpose AI providers”: https://digital-strategy.ec.europa.eu/en/faqs/guidelines-obligations-general-purpose-ai-providers
3. European Commission, “AI Omnibus enters into force”: https://digital-strategy.ec.europa.eu/en/news/ai-omnibus-enters-force
4. Regulation (EU) 2026/1744: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32026R1744
5. European Commission, “Navigating the AI Act”: https://digital-strategy.ec.europa.eu/en/faqs/navigating-ai-act
6. APRA, “Prudential Standard CPS 230 Operational Risk Management”: https://www.apra.gov.au/standards/cps-230
7. APRA, “Prudential Standard CPS 234 Information Security”: https://www.apra.gov.au/standards/cps-234
8. Regulation (EU) 2024/1689, Artificial Intelligence Act: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R1689