An Enterprise Customer Just Told You They've Modified Your AI Hiring Tool for Their Own Workflows: How to Answer the Article 28 Questions

An enterprise customer just told you they've modified your AI hiring tool for their own workflows: how to answer the Article 28 questions

Your customer success lead forwarded you a message from a 12,000-employee insurance group that has been using your AI candidate screening tool for eight months. They have built a proprietary scoring layer on top of it — weighting certain outputs to match their internal hiring rubric — and their legal team has just raised a concern:

"Our legal counsel has flagged Article 28 of the EU AI Act, which says that if a deployer modifies a high-risk AI system substantially, they may become the provider. We need to understand whether this applies to our workflow customisation and what obligations it creates."

This is a question your sales and legal team will see more as enterprise buyers understand the regulation. Here is what Article 28 says and how you answer it.

What Article 28 Actually Says

Article 28 addresses the situation where a person or organisation other than the original provider modifies a high-risk AI system substantially enough that the modified system must be considered a new system for regulatory purposes. When that happens, the modifier — typically your deployer — becomes the new provider and takes on the full obligations of Chapter III, Section 4: technical documentation, risk management, post-market monitoring, conformity assessment, and registration.

Article 28(1) sets out three circumstances where a deployer becomes a provider:

The deployer puts their own name or trademark on the system. If your customer re-brands the tool as their own product, they take on provider obligations.

The deployer makes a substantial modification. "Substantial modification" means a change that affects the system's compliance with the requirements in Chapter III, Section 2, or alters its intended purpose so that the modified system is required to undergo a new conformity assessment.

The deployer changes the intended purpose of a non-high-risk system so that it becomes high-risk. If your product was not classified as high-risk but the deployer's use case puts it into an Annex III category, they become the provider for that use case.

What "Substantial Modification" Means in Practice

The distinction between permitted customisation and substantial modification is operationally important. It determines whether your customer is still a deployer operating under their Article 26 obligations — or whether they have become a new provider who must independently meet Article 16 requirements.

Permitted customisation includes: configuring parameters you designed to be configurable, applying your system to a use case within the intended purpose you documented, and making workflow-level decisions about how outputs are used. These do not transfer provider status.

Substantial modification includes: altering the underlying model or its training; adding components that change how the system's risk-relevant outputs are generated; changing the intended purpose to a different high-risk category than the one you documented; or disabling or overriding the human oversight mechanisms you designed into the system.

The scoring layer your customer has built is likely to be assessed on whether it changes how the system generates its risk-relevant output — candidate screening decisions — or whether it merely re-weights outputs downstream of the AI's core process. The former is potentially a substantial modification; the latter is likely permitted configuration.

How to Answer the Question

A clear, practical answer to your customer's legal team looks like this:

First, distinguish what your customer has built. If their scoring layer operates downstream of your AI system's outputs — taking the scores your system produces and applying a weighting formula that their managers configure — it is almost certainly not a substantial modification. It is a workflow decision about how to use outputs, which is a deployer prerogative under Article 26(1)(a).

If, however, they have added a component that feeds into your model's inference process, bypasses the human-in-the-loop mechanism you designed, or generates scores based on attributes your system was not designed or assessed to use, that is a different analysis.

Second, give them a written position. Your answer should state: (a) what modifications fall within the intended purpose and permitted configuration under your technical documentation; (b) what modifications would constitute a substantial modification and transfer provider status; and (c) what changes to your system your team would need to review before your customer makes them, to ensure the compliance analysis can be updated.

Why This Matters for Your Next Enterprise Deal

More enterprise buyers are building customisation layers on top of AI vendor systems — this is a normal part of enterprise software adoption. The buyers who are asking this question are the sophisticated ones. They want a vendor who has thought through Article 28 and can give them a clear answer about where the compliance boundary sits.

A vendor who can say "here is what we classify as permitted configuration versus substantial modification, and here is the process for reviewing anything in the grey zone" wins deals against vendors who say "ask your lawyers."

Try Complizo free at complizo.com