A New Era of AI Governance
The EU AI Act is the world’s first comprehensive regulatory framework for artificial intelligence. It introduces a risk-based approach, imposing strict obligations on high-risk AI systems.
As enterprises adopt generative AI and experiment with prompt engineering, a practical question emerges:
👉 When does a “prompt change” remain just normal use, and when does it become a substantial modification that triggers new assessment and reporting obligations under the EU AI Act?
The Core Principle: Substantial Modification
According to the Act, once an AI system is “substantially modified”, it is treated as a new system and must undergo a new conformity assessment (European Parliament, 2024).
A substantial modification includes changes to:
-
The system’s intended purpose
-
Its architecture, model, or training data
-
Its rules or decision-making logic
-
Its risk profile in terms of safety, rights, or compliance
This makes it critical for organizations to understand when a prompt crosses from use into modification.
Prompt Changes vs. System Changes
Not all prompts are created equal. The Act distinguishes between usage and modifications:
-
Minor Prompt Changes: Adjusting wording to refine an answer is normal use, not a modification.
-
Operational Prompt Libraries: When standardized prompts systematically shape outputs (e.g., enforcing compliance checks), they effectively create new rules. If those rules impact outcomes, regulators may see this as altering the system’s purpose.
-
Prompts Driving New Rules or Decisions: Directing an AI to change how it evaluates risks, applies scoring, or gives regulated advice alters its decision-making framework. That shift can classify as a substantial modification.
-
Domain Shifts: Using the same AI chatbot with different prompts to give HR hiring advice one day and financial credit scoring the next repurposes the system. Each domain carries new risks, requiring reassessment.
-
Continuous Learning via Prompts: If prompts are fed back into training loops (fine-tuning or reinforcement learning), they modify the model itself, making conformity reassessment necessary.
👉 The key test: Do the prompts alter the system’s rules or decisions in ways that affect compliance or risk? If yes, it is no longer “just prompting”.
Reporting and Assessment Obligations
If prompts amount to a substantial modification, enterprises must:
-
Carry out a new conformity assessment (Annex VII).
-
Update their risk management systems and technical documentation.
-
Notify authorities (such as the designated national supervisory body).
-
Extend post-market monitoring to reflect the AI’s new scope and behavior.
When Does a Deployer Become a Provider?
Under the EU AI Act, the role of a Deployer typically applies to organizations that use AI systems developed by others. In this role, you are responsible for safe use, human oversight, and compliance with applicable obligations — but you are not responsible for the underlying system itself.
However, a Deployer may become a Provider if they substantially modify the AI system or repurpose it beyond its intended use. This happens when you alter the default behavior of a Large Language Model (LLM) through technical or functional changes that affect how the model operates.
Examples where a Deployer may become a Provider:
-
Model Fine-Tuning: Training the LLM further with your own datasets to change its knowledge base or responses.
-
Domain Repurposing: Modifying outputs so that the model acts as a legal advisor, financial consultant, or healthcare professional — i.e., providing regulated advice.
-
Automated Decision-Making: Using the LLM to take direct decisions without human validation, such as:
-
Approving or rejecting loan applications
-
Screening CVs and matching them to job descriptions
-
Prioritizing patients in a hospital or customers in a call center queue
-
Assessing insurance claims automatically
-
Assigning credit scores or fraud risk levels
-
-
Embedding into Core Processes: Integrating an LLM into ERP or CRM systems so it autonomously executes tasks (e.g., negotiating supplier contracts, approving invoices).
-
High-Risk Environments: Deploying LLMs in education, justice, or critical infrastructure contexts where outputs directly impact people’s rights or safety.
Deployer vs. Provider – Visual Summary
Not every organization that uses AI automatically becomes a Provider under the EU AI Act. The distinction depends on whether you simply use the system as it is (Deployer) or whether you substantially modify its behavior or purpose (Provider). The table below illustrates this difference with practical examples.
| Role | Definition | Examples | Key Responsibility |
|---|---|---|---|
| Deployer | Uses an AI system as provided by a third party, without substantially modifying its behavior or intended purpose. | – Using LLMs for drafting documents with human review before publication.
– Chatbot answers FAQs, but humans handle escalations. – AI suggests CV matches, but recruiters decide final selection. |
Ensure safe use, human oversight, data protection, and compliance with usage obligations. |
| Provider | Develops or substantially modifies an AI system, making it effectively a new system under the Act. | – Fine-tuning a model with your own datasets. – Modifying outputs so LLM provides legal, medical, or financial advice.
– Letting LLM approve loans, reject insurance claims, or prioritize hospital patients automatically. – Embedding LLM into ERP/CRM systems to autonomously approve invoices or contracts. |
Must perform conformity assessment, register the system, maintain risk management, technical documentation, and post-market monitoring. |
Takeaway: When in doubt, keep a human in the loop. By ensuring oversight and final decision-making remain with people, organizations can avoid unintentionally becoming Providers and stay compliant as Deployers under the EU AI Act.
Practical Guidance for Enterprises
To stay compliant while experimenting with prompts:
-
Define Prompt Boundaries: Document which prompts are “safe” vs. which could alter purpose or rules.
-
Govern Prompt Libraries: Treat shared prompts as code — versioned, reviewed, and audited.
-
Assess Rule & Decision Impact: If a prompt changes how the system makes decisions, treat it as a possible modification.
-
Monitor Domain Shifts: Repurposing into new sectors should trigger risk reassessment.
-
Stay Close to Regulators: The EU AI Office and national authorities will issue further guidance. Stay aligned.
Conclusion – Rules and Decisions Are the Red Line
Prompts may appear harmless, but under the EU AI Act they can, in some cases, reshape the rules or decisions an AI system applies. When this happens, the AI may be considered substantially modified, triggering new assessment and reporting obligations.
Enterprises need to treat prompt engineering with the same discipline as software engineering: governed, version-controlled, and audited.
In short:
-
If prompts only refine answers → usage.
-
If prompts alter rules, decisions, or purpose → modification.
Trust, compliance, and accountability depend on making this distinction clear.
👉 Do you agree? Should prompt libraries be treated like “code” and fully governed under the EU AI Act?