The same question - what controls, what framework, what do we tell the customer - has three different answers depending on where you sit in the supply chain. Worked against OWASP and the EU AI Act as amended.
Written for the person who has to answer a customer security questionnaire about AI, and for the risk owner who has to sign it.
Version 1.1 · updated 2026-09-04
The Digital Omnibus on AI - Regulation (EU) 2026/1744 - was published in the Official Journal on 24 July 2026 and entered into force on 27 July. It deferred the high-risk obligations that most published guidance still dates to August 2026, softened the AI literacy duty, and added two new outright prohibitions. The 2 August 2026 transparency deadline did not move.
Article 5
Original prohibited practices
2 February 2025
Social scoring, subliminal manipulation, real-time biometric ID. Unchanged
Article 4
AI literacy
2 February 2025
Softened by the Omnibus from 27 July 2026. Still binding
Chapter V
GPAI model obligations
2 August 2025
Sit with the model provider, not you
Article 50
Transparency
2 August 2026
NOT deferred. In effect for one month
Article 5 (new)
NCII and CSAM generation banned
2 December 2026
New prohibited practice. Up to EUR 35M or 7% of global turnover
Contract-reading agent with RAG over internal policy
An agent reads an inbound customer RFP or contract, extracts the privacy and security requirements, retrieves against internal policies, procedures and regulatory positions, drafts a response, and routes it to the solutions and legal teams for sign-off before it goes back to the customer.
Your role: Deployer
You built it, you run it, you use it internally. You are not placing it on the market, so provider obligations do not attach. The output leaves your organisation but the system does not.
What breaks
ASI01Agent Goal Hijack
The RFP is a document written by someone outside your organisation and handed to you. That is the definition of attacker-controllable input, and you are feeding it to an agent that then reads your internal corpus. Instructions hidden in a contract PDF are the cleanest indirect injection vector in this whole set.
LLM02Sensitive Information Disclosure
The failure that ends careers. Retrieval pulls an internal risk position, an unremediated audit finding or a pricing floor into a document that goes out under your letterhead. Retrieval does not know what is releasable.
ASI09Human-Agent Trust Exploitation
Legal and solutions review is the control you are relying on. OWASP names the failure mode where fluent, confident output gets approved rather than checked. Your one gate is a listed risk, and it degrades precisely as the tool proves useful.
LLM07Misinformation
A hallucinated privacy commitment in an RFP response is not an accuracy problem, it is a contractual representation. If it survives review it becomes something you owe.
LLM09Vector and Embedding Weaknesses
If the policy corpus is not partitioned by classification and audience, retrieval will not respect need-to-know. Most internal document stores are not partitioned that way.
ASI06Memory and Context Poisoning
If RFP content persists into the retrievable store, one customer's document shapes the response drafted for the next. Cross-engagement contamination is both a security and a confidentiality breach.
Where the AI Act lands
Article 4In force now
AI literacy. Your reviewers must be competent to review AI output. Note the Omnibus softened this from a duty to ensure literacy into a duty to take measures supporting it, and states expressly that no particular level need be guaranteed for any individual. The legal floor dropped; the ASI09 risk below did not move at all. Treat the obligation as the minimum and the risk as the reason.
Annex IIIDoes not apply
Proposal drafting is not a listed high-risk use. Nothing in Chapter III attaches, deferred or otherwise.
Article 50Our position: disclose
Whether a human-reviewed business document triggers a statutory disclosure duty is unsettled, and probably not. Disclose anyway. The asymmetry decides it: disclosing when you did not have to costs almost nothing, while a customer discovering later that an AI drafted the commitments in your proposal costs the relationship and weakens you in any dispute about what those commitments meant. Note this is a voluntary position taken on risk grounds, not Article 50 compliance - that duty attaches to defined categories and is not discharged by a footer.
The constraint that comes first
The customer's contract is their confidential information, usually under NDA. If your model is third-party hosted and that provider is not a named subprocessor in the agreement covering that document, you cannot feed it - and no security control fixes that. Settle the contract question before the architecture question.
Answering the customer
Frame it as document handling, not AI. The customer wants to know their contract does not leave your processing boundary and does not train anything. Lead there.
Your billing platform ships an AI feature. Users upload files and data tables and it performs spreadsheet-style manipulation to return a requested view of the data. You did not procure it separately and you cannot configure its internals.
Your role: Deployer, with almost no control surface
The SaaS vendor is the provider. The model vendor behind them carries the GPAI obligations. You are two steps removed from every technical decision that matters, which is the defining fact of this scenario.
What breaks
LLM02Sensitive Information Disclosure
Billing data is personal data and financial data at once. It is now in a third-party model context whose retention, logging and training behaviour you are taking on assertion.
LLM09Vector and Embedding Weaknesses
Multi-tenant SaaS. Cross-tenant retrieval bleed is the nightmare case and you have no means to test for it. You are accepting this risk whether or not you have named it.
ASI05Unexpected Code Execution
Spreadsheet manipulation on uploaded tables almost certainly means generated code executing against your data. That is a code interpreter running in someone else's estate on your billing records.
LLM10Improper Output Handling
A wrong slice of billing data does not look like a security incident. It looks like a commercial decision made on a number nobody re-derived.
ASI04Agentic Supply Chain
This capability arrived inside a product you had already approved. It almost certainly did not go through the assessment a standalone AI tool would have faced.
Where the AI Act lands
Article 4In force now
AI literacy applies to you as deployer even though you built nothing. Softened by the Omnibus to an obligation of effort, but users pasting billing tables into an AI feature still need to know what it does and does not guarantee - and that is a control question before it is a compliance one.
Chapter VProcurement lever
GPAI obligations have applied to the model provider since August 2025. You can require your SaaS vendor to pass through that documentation. Most buyers do not know to ask, and it is the sharpest procurement lever available here.
Annex IIIDoes not apply
Billing analytics is not a listed high-risk use.
The constraint that comes first
This is where the answer is often no. If the vendor will not commit in writing to no-training on your data, a named subprocessor list, and processing location, then for EU customer data the feature stays off. That is a configuration decision available to you today, and it is the strongest control you have.
Answering the customer
Be honest that the OWASP control set is largely unavailable to you here. You cannot sandbox it, validate its output handling or partition its retrieval. Your entire control surface is contractual, configurational and who-you-let-use-it. State that plainly rather than implying technical assurance you do not have.
Open-weights model in private cloud, building a CRM agent for a customer
A DevOps team runs a third-party open-weights LLM inside your private cloud and uses it to develop an agentic CRM product, which is then delivered to a customer to operate.
Your role: Provider - and this is the finding
You are placing an AI system on the market under your own name. That is a categorically heavier position than the other two scenarios, and teams routinely misread it as deployment because the model came from someone else. Your customer becomes the deployer. Obligations split accordingly and your contract should say so explicitly.
What breaks
ASI04Agentic Supply Chain
Open weights are an unverified binary artifact from a public repository. OWASP names poisoned pre-trained models and malicious deserialization distributed this way. Provenance, hash pinning and an AI bill of materials are the baseline, and private cloud hosting does nothing for any of it.
ASI05Unexpected Code Execution
Coding agents that generate and run code have produced the highest concentration of real incidents in OWASP's own tracker over the past year. This is the build pipeline, not the product, and it is where the damage has actually landed.
ASI03Identity and Privilege Abuse
A CRM agent acting under a shared service identity across customer records is the confused-deputy case. Per-agent identity and short-lived scoped credentials are a design decision you can only make now, before delivery.
ASI02Tool Misuse and Exploitation
A CRM agent with write access to records and an email tool is the classic internal-query-to-external-exfiltration chain. Tool scoping is your decision to make and your customer's risk to carry.
LLM05Data and Model Poisoning
Fine-tuning or adapting the weights extends the poisoning surface to your own pipeline and to anything you feed it.
ASI10Rogue Agents
The residual. Behavioural drift in a system you no longer operate but are still named on. Kill switches and behavioural baselines have to be built in before handover, not retrofitted.
Where the AI Act lands
Article 4In force now
Applies to you as provider and, separately, to your customer as deployer. Softened by the Omnibus to an obligation of effort. Worth noting your customer will still ask what you did about it.
Article 50In force now
In effect since 2 August 2026. If the CRM agent interacts with natural persons, disclosure attaches now. This is the only obligation in these three scenarios that is both live and genuinely demanding, and it was not deferred.
Article 5 (new)In force now
From 2 December 2026, AI systems that generate non-consensual intimate imagery or CSAM are outright prohibited. A CRM agent is not the target, but the prohibition reaches any provider whose system produces such output as a reasonably foreseeable outcome, not only those who designed it to. If your agent has any open-ended image or text generation surface, that is a foreseeable-misuse assessment you owe as provider, in the tier carrying the heaviest penalties.
Annex IIIDepends on design
CRM is not inherently high-risk. It becomes high-risk if the agent touches creditworthiness, employment decisions or access to essential services. That is a design choice made by a developer, not a compliance question answered later. Decide it deliberately and record the decision.
Chapter IIIDeferred
If it does turn out to be high-risk, the deadline is 2 December 2027, not August 2026. You have roughly fifteen months, and harmonised standards are still not published.
Chapter VUnsettled
Whether fine-tuning an open-weights model makes you a downstream provider of a modified GPAI model is contested and unresolved. If you fine-tune, get advice rather than assuming you are clear.
The constraint that comes first
Check the model licence before anything else. Open-weights licences carry acceptable-use terms that flow through to your customer, and some restrict exactly the commercial redistribution this scenario describes. It is a delivery blocker that has nothing to do with security and is discovered late with painful regularity.
Answering the customer
Your customer will send you the questionnaire you have been sending your own vendors. Answer it as a provider: model provenance, what you fine-tuned on, tool scope and identity model, your Article 50 position, and where the high-risk line sits for their intended use. Say plainly which obligations transfer to them on handover.
What actually changes across the three
Same technology, three roles, three obligation loads. Scenario 1 deploys its own system, scenario 2 deploys someone else's, scenario 3 places one on the market. Only the third carries provider obligations, and it is the one most often mistaken for the other two because the model was somebody else's.
Your control surface shrinks as you move away from the build. Scenario 3 can fix things in architecture. Scenario 1 can fix things in configuration and process. Scenario 2 can mostly only choose whether to turn it on. A control catalogue that ignores this hands all three the same list.
None of these three is high-risk under the AI Act today, and the high-risk deadline moved to December 2027 regardless. The obligations actually live for all three are AI literacy since February 2025 and transparency since last month. Guidance still dating high-risk to August 2026 is describing a deadline that no longer exists.
In two of three scenarios the binding constraint is contractual, not technical. Confidentiality of a customer's contract, and a model licence's acceptable-use terms. Both are settled before a security control is chosen, and both are routinely discovered afterwards.
Scope and limits
This is a reasoning aid, not legal advice and not a compliance mapping. It works three concrete architectures against public frameworks and shows how the answers diverge. Every architecture differs in ways that change the analysis; use this to structure the question, not to skip it. Framework names and article numbers are cited so you can check them.
ISO/IEC 42001 Annex A control identifiers are deliberately absent. The standard is not freely available and citing control numbers from memory is how mapping documents acquire errors. Where 42001 is relevant we name the management-system function rather than a clause.
Frameworks referenced: OWASP Top 10 for Agentic Applications 2026 (ASI01–ASI10)
and OWASP Top 10 for LLM Applications 2026 (LLM01–LLM10), both OWASP GenAI Security
Project, CC BY-SA 4.0. Regulation (EU) 2024/1689 as amended by the Digital Omnibus on AI,
in force 27 July 2026.