A polished AI demonstration can show what a product does when the vendor controls the data, prompts and environment. It cannot show whether the system will disclose AI interaction appropriately, mark generated content reliably, preserve evidence after an update or support the organisation when a transparency control fails.

That difference is becoming more consequential.

Article 50 of the EU AI Act applies from 2 August 2026. It introduces transparency requirements covering certain interactive and generative AI systems, machine-readable marking of AI-generated or manipulated content, emotion-recognition and biometric-categorisation systems, deepfakes, and some AI-generated text published on matters of public interest.

The timing deserves careful attention. The EU’s AI Omnibus entered into force on 27 July 2026 and extended the application dates for certain high-risk AI rules. However, the European Commission’s current Article 50 transparency guidance confirms that the transparency obligations covered here apply from 2 August 2026.

For procurement teams, the practical lesson is straightforward: do not ask only whether an AI vendor claims to be “AI Act ready”. Ask what the product does, what evidence supports the claim and what happens when the system changes.

What Article 50 means for AI procurement

Article 50 does not impose one identical obligation on every organisation using AI.

Responsibilities depend on factors including:

• Whether an organisation is acting as a provider or deployer.
• How the system is made available and used.
• Whether people interact directly with the AI.
• Whether the system generates or manipulates audio, images, video or text.
• Whether emotion recognition or biometric categorisation is involved.
• Whether generated text concerns a matter of public interest.
• Whether meaningful human review or editorial control takes place.

The distinction matters because a vendor may be responsible for building a technical marking capability, while the purchasing organisation may still be responsible for how disclosures are presented to users or how generated material is published.

Procurement therefore becomes part of governance. A buyer needs enough evidence to determine whether the product enables the organisation to meet its own obligations. Professionals who need a structured method for doing this can develop the relevant evaluation skills through the Certified AI Procurement and Vendor Evaluation Professional course.

The following questions are an operational starting point. They support informed procurement but do not replace use-case-specific legal advice.

1. What is the vendor’s role, and what role will our organisation assume?

Begin by asking the supplier to describe its expected role under the AI Act and the assumptions supporting that position.

A credible answer should identify:

• Who develops or places the system on the market.
• Who determines its intended purpose.
• Who configures, integrates and operates it.
• Whether your intended use differs from the vendor’s documented purpose.
• Whether substantial modification or rebranding could alter the allocation of responsibilities.

Do not accept “we are the provider and you are only the customer” without examining the deployment. Roles arise from what each party actually does, not simply from the terminology in the contract.

2. How does the system inform people that they are interacting with AI?

For systems that interact directly with individuals, ask the vendor to demonstrate the disclosure as an ordinary user would experience it.

The test should establish whether the notice is:

• Visible before or at the beginning of the interaction.
• Written in clear language.
• available across relevant devices and channels.
• Preserved when the interface is customised.
• Presented again when a material change affects the nature of the interaction.

A disclosure buried in general terms and conditions is different from an effective in-context notice. Procurement teams should review the actual interface, not merely a policy document.

3. How is AI-generated or manipulated content marked?

The Commission explains that providers of relevant generative AI systems must support machine-readable marking of AI-generated or manipulated outputs.

Ask the supplier:

• Which output formats are marked?
• What marking method is used?
• Is the mark retained after common editing, compression or export?
• Does marking operate by default?
• Can an administrator disable it?
• How is successful marking tested?
• What evidence can the vendor provide to demonstrate reliability?

A product should not receive full marks simply because it has a content-labelling setting. The buyer needs to know whether the control works in the intended workflow.

4. Which Article 50 obligations does the vendor believe are relevant to the use case?

Request a written scope analysis that connects product functionality to the relevant obligations.

The response should distinguish between:

• Interactive AI systems.
• Generative AI outputs.
• Emotion-recognition functions.
• Biometric-categorisation functions.
• Deepfake generation or manipulation.
• AI-generated text concerning matters of public interest.

Generic compliance statements are weak evidence. A useful analysis should identify both what is in scope and what the vendor believes is outside scope, together with the assumptions behind that conclusion.

5. What controls support deployer disclosures?

Some Article 50 responsibilities fall on deployers rather than providers. The purchasing organisation may therefore need configuration options, metadata, documentation or interface controls supplied by the vendor.

Ask whether the product enables the organisation to:

• Display a disclosure at the correct stage.
• Identify outputs that require labelling.
• Apply consistent labels across channels.
• Preserve disclosure records.
• Control who can remove or alter labels.
• Demonstrate that a disclosure was active at a particular time.

A vendor should explain not only what its product does automatically, but also what the customer must configure and maintain.

6. How does the system support human review and editorial control?

Human review is not established by adding an approval button. The review must be meaningful within the workflow.

Ask the vendor to demonstrate:

• Where review occurs.
• What information the reviewer receives.
• Whether the reviewer can reject, amend or regenerate content.
• Whether the reviewer’s decision is recorded.
• Whether publication can bypass the review stage.
• How reviewer authority is managed.
• Whether automated bulk publication changes the control.

This question is particularly important for content involving public-interest matters. The Commission’s guidance distinguishes AI-generated public-interest text without human review or editorial control, so the purchasing organisation should be able to demonstrate what its review process actually involves.

7. Are disclosures understandable and accessible?

A technically present notice may still be ineffective if users cannot understand or perceive it.

Include disclosure presentation in accessibility and user-acceptance testing. Examine:

• Screen-reader compatibility.
• Mobile presentation.
• Language versions.
• Voice and telephone interactions.
• Timing and duration.
• Colour contrast.
• Age-appropriate communication where relevant.
• Disclosure within third-party interfaces.

The objective is not simply to locate a notice somewhere in the system. It is to ensure that affected people receive understandable information in context.

8. What evidence will the vendor provide?

Request a defined evidence pack before contract award rather than accepting a future promise to supply documentation.

Depending on the product and risk, useful evidence may include:

• Product and system documentation.
• Intended-purpose statements.
• Data-flow diagrams.
• Marking and labelling specifications.
• Test reports.
• Model and system version records.
• Known limitations.
• Subcontractor information.
• Incident-response procedures.
• Change logs.
• Customer configuration guidance.
• Independent assurance reports.

The NIST AI Risk Management Framework Playbook organises risk-management actions across Govern, Map, Measure and Manage. Although voluntary and not an AI Act compliance mechanism, it provides a useful structure for examining whether a supplier’s assurances extend across the AI lifecycle.

9. Which third-party models and services sit behind the product?

Many AI products depend on foundation models, cloud services, data providers, moderation tools and other subcontractors. The contracting vendor may not control every component directly.

Ask for:

• A current list of material AI and data dependencies.
• The purpose of each dependency.
• Relevant data locations and transfers.
• Notification arrangements when a dependency changes.
• The impact of upstream model updates.
• Continuity arrangements if a third-party service is withdrawn.
• Responsibility for failures originating upstream.

This is where ordinary supplier management and AI-specific governance intersect. The UK Information Commissioner’s Office recommends that organisations undertake appropriate due diligence before procuring AI systems, including consideration of accuracy, bias and design trade-offs. Its contracts and third-parties guidance also highlights information-flow mapping as a useful control.

10. How are transparency controls monitored after updates?

AI products change frequently. A control that passes during procurement may behave differently after a model, interface or integration update.

Ask the vendor to define:

• What constitutes a material change.
• Which changes require customer notification.
• Whether marking and disclosure tests are repeated.
• How regression testing is conducted.
• How long previous test evidence is retained.
• Whether customers can delay an update.
• What happens if an update causes a control to fail.

Ongoing monitoring should form part of the operating model, not an optional support service. The Case HQ’s practical guide to AI governance training explains why managers and functional specialists need the capability to interpret controls and apply them in real decisions rather than relying entirely on technical teams.

11. Will the vendor complete scenario-based acceptance tests?

Documentation should be tested against the intended use.

Create representative scenarios before purchase. For example:

1. A customer begins a conversation with an AI service agent.
2. The system generates an image for a public campaign.
3. A communications team produces public-interest text.
4. An administrator changes the interface configuration.
5. The underlying model is updated.
6. A user exports and edits generated content.

For each scenario, specify the expected disclosure, mark, human review, audit evidence and escalation route. The supplier should demonstrate the outcome in a test environment.

This approach also supports stronger adoption. As The Case HQ’s AI adoption case study shows, successful implementation depends on bounded use cases, review standards, governance and measurable workflow outcomes—not merely on selecting a capable tool.

12. What contractual commitments support the vendor’s claims?

The final question converts promises into enforceable operating expectations.

Consider contractual provisions covering:

• Accuracy of supplied compliance information.
• Notification of material system or model changes.
• Continued operation of marking and disclosure features.
• Access to relevant documentation and test evidence.
• Incident notification and investigation support.
• Cooperation with audits or regulatory enquiries.
• Subcontractor changes.
• Data return and deletion.
• Transition assistance and portability.
• Remedies when agreed controls fail.

Contract wording should reflect the organisation’s role, use case and risk exposure. Avoid broad clauses claiming that a product is “fully compliant with all AI laws”. Such language may sound reassuring while providing little clarity about the specific control, evidence or responsibility involved.

Use a five-part evidence gate

A practical procurement decision can be organised around five tests:

1. Claim

What exactly is the vendor promising?

Replace terms such as “responsible”, “transparent” or “compliant” with a precise statement about system behaviour.

2. Evidence

What documentation, test result or demonstration supports the claim?

A policy or certification may contribute evidence, but it should not automatically replace product-level assessment.

3. Test

Can the claimed control be reproduced in the buyer’s intended workflow?

Use realistic data, interfaces, roles and failure scenarios.

4. Owner

Who is responsible for configuring, monitoring and correcting the control?

Record responsibility across the vendor, customer, integration partner and any upstream provider.

5. Contract

What happens if the system changes or the control fails?

The agreement should address notification, support, remediation, evidence access and exit.

A vendor should pass all five stages for every material transparency claim. A strong claim with no test is incomplete. A successful test with no named owner will become unreliable. A control with no contractual support may disappear after an update.

A practical example: buying an AI customer-service agent

Consider an organisation buying an AI agent to answer customer questions and escalate difficult cases.

The vendor demonstrates accurate responses and smooth integration. However, the initial proposal does not explain whether customers are always told that they are interacting with AI.

Using the five-part gate, the procurement team requests:

• A precise statement explaining when the disclosure appears.
• Interface documentation and screenshots.
• Live tests across web, mobile and voice channels.
• Identification of the vendor and customer administrators responsible for the setting.
• A contractual commitment to notify the organisation before any change affecting the disclosure.

The team also tests a failed scenario: the web widget is embedded inside a third-party customer portal. The disclosure disappears because the portal suppresses the opening system message.

Without scenario testing, the system would have appeared ready. The failure is not necessarily a reason to reject the vendor, but it must be corrected before deployment and included in acceptance criteria.

Warning signs during AI vendor evaluation

Treat the following responses as signals for further investigation:

• “The AI Act does not affect customers.”
• “Our certification covers everything.”
• “The system is compliant by design.”
• “The disclosure is somewhere in the user terms.”
• “The model provider handles all marking.”
• “Customers are responsible for testing.”
• “We cannot identify our underlying models.”
• “Updates do not affect compliance.”
• “Detailed evidence is available after purchase.”
• “The contract cannot include regulatory-change support.”

A warning sign does not always prove that a product is unsuitable. It shows that the decision needs more evidence.

What procurement teams should do next

The EU’s AI Omnibus update of 27 July 2026 extended the timelines for certain high-risk AI requirements. That should not be interpreted as a general reason to postpone AI governance. Article 50 transparency requirements still apply from 2 August 2026.

Procurement teams should now:

1. Inventory AI products that interact with people or generate content.
2. Identify the organisation’s role and intended use.
3. Send the 12 questions to relevant suppliers.
4. Request evidence before accepting compliance claims.
5. Conduct scenario-based acceptance testing.
6. Assign internal control owners.
7. Align contract terms with the verified system behaviour.
8. Record the decision and review it after material changes.

Professionals responsible for these decisions can build a more systematic approach through the Certified AI Procurement and Vendor Evaluation Professional course. The programme develops practical capability in vendor assessment, governance, assurance, risk-aware procurement and evidence-based decision-making.

You can also review The Case HQ’s wider range of certified artificial intelligence courses for related learning in AI governance, operations, privacy and strategy.

Frequently asked questions

Does Article 50 apply to every AI system?

No. Its requirements depend on the system’s functionality, the organisation’s role and how the AI is used. Interactive AI, generative outputs, deepfakes, emotion recognition, biometric categorisation and certain public-interest text receive specific treatment. Organisations should assess their actual use case rather than apply a generic label.

Does purchasing an “AI Act-compliant” product make the customer compliant?

Not automatically. Providers and deployers can have different responsibilities. A purchasing organisation must still configure, operate, supervise and use the system appropriately for its role and use case.

Must all AI-generated content be labelled?

No. The rules are more specific than a universal requirement to label every AI-assisted output. The type of content, the system, the organisation’s role, the context and the presence of human review or editorial control can all affect the position.

Is an ISO certification enough to approve an AI vendor?

No single certification should replace use-case-specific due diligence. Certifications may provide valuable assurance, but buyers should still examine system behaviour, supporting evidence, contractual allocation, integration risks and ongoing monitoring.