Approve each AI component by use and market, or local AI laws will block deployment

If you lead vendor risk for a multinational, stop approving AI suppliers at the company level. Approve each component for a defined use and market, with local documentation, usage restrictions, logs, labeling duties, and contractual remedies, or you'll face blocked launches and liability your generic assurance never covered.

ISO/IEC 42001 or a broad vendor questionnaire can support an approval. Neither can prove that a particular component is lawful for employment screening in Europe, properly labeled in China, or covered by usable remedies if the supplier changes it.

The immediate risk is deadline confusion. The EU has delayed major obligations for high risk AI, but several duties are already in force or arrive much sooner. Treating the delay as a company wide pause turns a useful extension into compliance debt.

The extension leaves live duties in place

The EU Council approved the Digital Omnibus on AI on 29 June 2026 and moved most high risk AI compliance from 2 August 2026 to 2 December 2027. AI embedded in products covered by other EU legislation received until 2 August 2028 ¹.

Those dates matter for conformity work. They don't suspend the rest of the EU AI Act. The Act's transparency requirements take effect from August 2026, including notices when people interact with chatbots and labels for deepfakes or certain public interest content ². Some AI literacy and prohibited practice rules have applied since February 2025 ³.

That makes a blanket supplier approval dangerous. A vendor may have one component facing a future conformity deadline while another already needs a user notice. A third use may be prohibited entirely.

The financial exposure isn't theoretical. EU AI Act penalties for prohibited practices can reach €35 million or 7 percent of global turnover ³. For a vendor risk leader, the nearer consequence is often a launch stopped by legal or compliance because the approval file can't show which obligation applies to which component.

One supplier can create several legal objects

The EU AI Act classifies systems according to risk and imposes strict obligations on high risk uses, including systems used in employment and financial services ². A customer service chatbot from the same supplier may instead trigger a transparency duty. One approved supplier flag can't express that distinction.

Geography adds another layer. The United States relies largely on voluntary frameworks such as the NIST AI Risk Management Framework alongside state laws ³. China requires algorithm registration and sector specific content labeling ³. The UK uses lighter oversight through existing sectors ³.

Foley & Lardner describes ISO/IEC 42001 as a coordinated approach to AI governance across jurisdictions ³. Coordination is useful. It doesn't answer whether the buyer has the documentation, labels, or log access demanded for a particular deployment.

The approval object therefore has to be smaller than the vendor. It should identify the component, its intended use, and the market where it will operate. If any of those fields changes, the approval needs review.

This also changes how you read assurance reports. A supplier's mature governance program can lower general risk while leaving a local obligation unresolved. A questionnaire answer without supporting records or an enforceable remedy is compliance theater.

The delay is a capacity warning

The Digital Omnibus extension responded partly to delayed harmonised standards and the slow establishment of national authorities and conformity assessment bodies ¹. Those bottlenecks explain the extra time. They also warn buyers against waiting.

High risk systems must undergo rigorous risk assessment and maintain activity logs for traceability ². The Act also requires controls for dataset quality and evidence of robustness. Cybersecurity and accuracy are explicit requirements as well ². Providers face technical documentation and conformity assessment duties for high risk systems ³.

These obligations produce evidence over time. Logs need collection before they can show operating history. Dataset controls need owners before an assessor asks who approved a change. A policy signed just before the deadline won't replace records showing that the controls worked.

This is especially important for machinery or medical devices containing AI, which fall under the later product deadline described in the Digital Omnibus ¹. Assessment capacity may remain scarce. A buyer that discovers missing supplier documentation near the deadline could lose market access while waiting for the vendor and an assessment body to catch up.

Platform oversight exposes split inventories

The amended framework centralizes EU AI Office supervision of AI systems on large online platforms already covered by the Digital Services Act ¹. It also introduces a ban on intimate imagery created with AI ¹.

For platform trust and safety leaders, that makes separate inventories untenable. The AI governance team may record a model as approved while the moderation team records policy violations by feature or content type. Under combined scrutiny, the platform needs to connect those records and show that restrictions apply consistently to the component used in the EU.

That same need appears in procurement. An approval record must connect the supplier component to production enforcement and the resulting logs. Otherwise, the buyer has an assurance document with no way to prove what happened after launch.

Where AetherLab fits

AetherLab directly addresses this evidence problem through the Evidence Pack, which ties AI vulnerabilities and findings to business impact for approval decisions. Its scope is narrower than the procurement control described here: it isn't certification or legal advice, and approval decisions remain with the responsible institution. It also doesn't supply a vendor's local conformity documents or negotiate contractual remedies.

Build an approval record regulators and buyers can use

That boundary matters because the buyer still owns the approval architecture. Replace the single approved vendor field with a record for each component and deployment. At minimum, require the following:

• Component identity: Record the service, model version, supplier owner, technical dependencies, and interfaces that send or receive data. A vendor name alone isn't enough to detect a material change.

• Approved use and market: State the business purpose, affected users, jurisdiction, and prohibited uses. Tie approval to that scope. A component cleared for internal document search shouldn't inherit approval for ranking job applicants.

• Jurisdiction-specific documentation: Record the supplier's claimed risk classification and the buyer's regulatory role. Attach conformity documents where required. Name the person responsible for resolving gaps rather than marking them as generally accepted risk.

• Usage restrictions and labeling: Specify how each restriction reaches production. Record who owns chatbot notices or labels for synthetic content, where those notices appear, and what happens when they fail. A policy statement without an implementation owner isn't a control.

• Logs and control evidence: Require the event fields needed for traceability, an agreed retention period, and a way for the buyer to obtain records. Test a sample export before approval. If the supplier can't provide usable logs for a high risk component, the component shouldn't enter that market.

• Contractual remedies: Require notice when the supplier changes the component or its claimed legal status. Preserve the right to suspend the affected use and obtain records needed for an investigation. A clause that merely promises compliance won't help during an incident.

The record also needs change triggers. A new model version, expanded purpose, or additional market should reopen the relevant portion of the review. It shouldn't force a full reassessment of unrelated components from the same supplier.

Make component approval the release condition

Set one release rule: no AI component enters production until the record names its use, market, evidence owner, and remedy if the supplier fails. If required documentation or log access is missing, mark that component pending for that deployment instead of approving the company with an exception.

Most high risk AI compliance begins on 2 December 2027 under the amended schedule ¹. When that deadline arrives, I expect multinational buyers still using a single supplier approval flag to reopen large parts of their vendor portfolios under pressure. Teams approving by component, use, and market will be able to show exactly which deployments can proceed.