What Expanding EU AI Model Evaluation Means for Manufacturing Companies in Europe

Direct answer: The European Commission is expanding the EU's capacity to independently evaluate AI models, with a target of operational status by 2027. For manufacturing companies in Europe, this means any AI feature embedded in your products, internal tools, or customer-facing software will increasingly need to be built to survive formal scrutiny, not just marketing claims — so the software decisions you make in 2026 determine how painful that scrutiny is later.

In 2026, the European Commission signaled a push to expand model-evaluation capacity across the EU, aiming to have that evaluation infrastructure operational by 2027. This is not a headline about a single new law — it's about building the actual technical machinery that regulators will use to test, audit, and validate AI models against the standards set out under the EU's AI governance framework. For manufacturing companies, which increasingly run AI on the factory floor, in supply chain forecasting, in predictive maintenance, and in customer-facing configurators, this matters because it signals that "we use AI" is moving from a marketing line to a claim that can be independently checked. Manufacturers that have quietly bolted AI features onto legacy systems, or that rely on opaque third-party models without documentation, are the ones most exposed when evaluation capacity comes online. We don't have a precise figure for how many EU manufacturers currently document their AI systems to an audit-ready standard — that number isn't publicly available for this specific angle — but the general pattern across manufacturing digitization is clear: most industrial AI deployments were built for speed, not for scrutiny, and that gap is what the 2027 timeline is meant to close.

What the EU Is Actually Building, and Why It's Real

The expansion the European Commission described in 2026 is about evaluation infrastructure — the technical capability to test AI models against defined benchmarks for safety, reliability, and compliance, rather than relying purely on self-reported conformity from the companies deploying them. This is a meaningful shift because it changes who holds the burden of proof. Under a self-assessment regime, a manufacturer can claim its predictive-maintenance model is accurate and low-risk and largely be taken at its word, provided documentation exists. Under an evaluation regime with real technical teeth, that claim can be tested against a model's actual behavior, training data provenance, and failure modes.

This is a real trend, not speculation, because building evaluation capacity is expensive and slow — governments don't stand up this kind of technical infrastructure unless they intend to use it. A 2027 operational target gives industry a runway, but it's not a distant one. Software procurement cycles, vendor contracts, and internal AI rollouts that manufacturers greenlight in 2026 will still be running when evaluation capacity comes online. Systems built without traceability, versioning, or explainability baked in will be expensive to retrofit under pressure; systems built with those things from the start will simply need documentation assembled.

Why This Isn't Just a Compliance Story

It's tempting to file this under "legal will handle it," but the technical reality sits with whoever builds and maintains your software. Evaluation regimes test things like: can you show what data trained or fine-tuned a model, can you demonstrate consistent behavior across versions, can you explain a specific output tied to a specific product decision. Those are engineering questions before they are legal ones. A manufacturer's software vendor — internal team or external partner — is the one who has to answer them in practice.

There's also a subtler point worth sitting with: evaluation capacity, once it exists, doesn't just sit idle waiting for complaints. Infrastructure like this tends to get used proactively — sector-by-sector reviews, spot checks tied to product categories, or scrutiny triggered by an unrelated incident that happens to draw attention to an entire industry's practices. Manufacturing, given how directly its AI systems touch physical safety (a misjudged predictive-maintenance alert, a miscalibrated quality-control model) and commercial outcomes (an AI-driven quote that under- or overstates cost), is a plausible candidate for that kind of sector attention once the tooling exists to support it.

Why This Matters Specifically for Manufacturing Companies in Europe

Manufacturing has adopted AI faster than its governance processes have kept pace with, and that gap is exactly what expanding evaluation capacity is designed to expose. Three areas make manufacturers particularly exposed:

Predictive maintenance and quality control models. These systems often run on sensor data feeding into models that flag anomalies or predict failure. If those models were built or fine-tuned by a vendor who didn't preserve training data lineage or version history, a manufacturer inherits a black box it can't fully explain — precisely what evaluation frameworks are designed to probe.

Supply chain and demand forecasting tools. These increasingly incorporate AI-driven recommendations that affect procurement and production decisions. When those recommendations influence real commercial outcomes, at some point someone will ask how the model reached them, and "the vendor's dashboard just shows a number" is not an answer that survives scrutiny.

Customer-facing configurators and B2B ordering platforms. More manufacturers now offer AI-assisted product configuration or quoting tools on their websites. These are visible, external-facing systems — exactly the kind that regulatory attention tends to reach first, because customers and competitors can see them directly.

For European manufacturers specifically, there's an added layer: much of this equipment, software, and data infrastructure was built over years by different vendors with different standards, so the audit trail is often fragmented across systems that were never designed to talk to each other, let alone produce a coherent compliance record. A predictive-maintenance model might sit on one vendor's edge device, a forecasting tool on a separate SaaS platform, and a customer-facing configurator on a third system entirely — none of them sharing a common logging standard or a single place where "what did this model decide and why" can be answered consistently.

There's also a competitive dimension manufacturers tend to underweight. As evaluation standards become concrete, they'll start showing up in procurement requirements from larger buyers, especially in automotive, industrial equipment, and other supply chains with multiple tiers of manufacturers feeding into a prime contractor. A manufacturer that can produce clean documentation of how its AI-driven quality checks or forecasting tools work becomes a lower-risk supplier to work with; one that can't becomes a liability further up the chain gets nervous about. In other words, this isn't purely a regulator-facing concern — it increasingly becomes a business-development one, since larger customers will ask the same questions a regulator eventually might.

How This Compares to Other Regulatory Shifts Manufacturers Have Already Absorbed

Manufacturing companies in Europe have lived through waves of regulatory change before — environmental reporting requirements, product safety directives, data protection rules following GDPR. The pattern each time has been similar: early requirements were broad and somewhat abstract, then enforcement infrastructure caught up and turned abstract principles into concrete, testable obligations. AI model evaluation is following the same arc. The difference this time is that the underlying systems being regulated — AI models — are newer, less standardized, and often less understood internally than the systems governed by prior regulatory waves.

That difference matters practically. When GDPR enforcement caught up with data practices, most manufacturers already had IT and data teams who understood roughly what data they held and where. With AI, that same institutional knowledge often doesn't exist yet — many manufacturers can tell you which vendors supply their AI tools but can't tell you, with confidence, what data trained the underlying models or how those models have changed across vendor updates. Closing that knowledge gap is itself the first piece of work, independent of any specific technical fix.

There's a useful lesson in how GDPR compliance actually played out for manufacturers: the companies that treated it as a one-time paperwork exercise ended up redoing the work repeatedly as their systems evolved, while the ones that built data governance into their engineering processes absorbed each subsequent change with far less disruption. AI model evaluation is likely to follow the same pattern. Treating this as a checklist to complete once, rather than a standard to build into how software gets developed going forward, means facing the same scramble again with the next model update, the next vendor swap, or the next AI feature a product team wants to ship.

What Changes in Practice for Your Website, App, and Internal Software

The practical shift is that "does it work" is no longer sufficient — the standard becomes "can you show how and why it works, on demand." That changes several concrete things about how manufacturing software should be built and maintained going forward.

Documentation and Traceability Become Product Requirements, Not Afterthoughts

If an AI feature — whether it's a recommendation engine on a B2B ordering portal or an internal forecasting tool — can't produce a clear record of its inputs, versions, and decision logic, it becomes a liability the moment evaluation capacity exists to test it. This means model versioning, data provenance logging, and decision audit trails need to be architected into the software from the start, not bolted on afterward. Retrofitting traceability into a system that wasn't designed for it is significantly more expensive than building it in from day one — which is exactly the kind of foundational work that falls under Custom Software Development, where the system is architected around your actual compliance and audit needs rather than assembled from generic off-the-shelf modules that assume none of this matters.

Vendor and Third-Party Model Dependencies Need Scrutiny

Many manufacturers license AI capabilities from third-party platforms rather than building in-house. That's a legitimate strategy, but it introduces a dependency: if your vendor can't produce evaluation-ready documentation for the model underneath their tool, that risk becomes yours by extension. Manufacturers should be asking vendors now — not in 2027 — what documentation, versioning, and explainability their systems actually support, and building contracts and internal architecture that don't assume the vendor will simply handle it.

Legacy Systems Need an Honest Audit

A lot of manufacturing software — ERP integrations, floor-level monitoring dashboards, older e-commerce or B2B ordering platforms — was built in phases by different teams over years. It's worth stepping back and treating your customer-facing digital presence the same way you'd treat a production line: does it perform reliably under real conditions, not just in the demo. The same logic that applies to Ecommerce Site Speed: Why Slow Product Pages Cost You Sales applies here — a system that technically functions but degrades under real scrutiny (slow, undocumented, inconsistent) is a liability whether the scrutiny comes from customers abandoning a cart or a regulator asking for a model's decision history.

Custom Builds Give You Control Legacy Platforms Don't

Manufacturers running heavily customized storefronts or ordering platforms, particularly those built on flexible commerce frameworks, are in a better position here than those on rigid, vendor-locked systems. The pattern described in Shopify Custom Development for Growing Brands — building bespoke logic on top of a flexible platform rather than accepting whatever a template allows — is directly relevant: it's the difference between being able to add audit logging and explainability to your AI-driven features versus being stuck waiting on a platform vendor's roadmap.

This distinction becomes sharper the more AI is embedded into a manufacturer's digital storefront. A rigid platform that bundles an AI recommendation engine as a black-box add-on gives you no way to instrument it — you can't see what data drives a given recommendation, you can't version the underlying logic, and you certainly can't produce documentation on demand if asked. A custom-built system, by contrast, lets you decide exactly what gets logged, how model versions are tracked, and how a given output can be traced back to its inputs, because you control the code rather than renting access to someone else's.

Internal Tools Deserve the Same Scrutiny as Customer-Facing Ones

It's easy to focus attention on customer-facing systems because they're visible, but internal tools used for production scheduling, inventory allocation, or quality thresholds carry real exposure too, particularly when their outputs affect worker safety or product quality. An internal dashboard that quietly incorporates a machine-learning model to flag "at-risk" production batches needs the same versioning and explainability discipline as a public-facing configurator — the fact that customers never see it doesn't reduce the underlying risk if the model's judgment turns out to be wrong or untraceable.

What Manufacturers Should Do About It Now

The sensible response isn't panic or a compliance overhaul overnight — it's treating 2026 as the window to build (or rebuild) AI-touching software with traceability and explainability as design requirements, so that by the time evaluation capacity is operational, you're producing documentation rather than scrambling to reconstruct it.

Practical Steps

1. Inventory every AI-touching system — internal tools, customer-facing configurators, forecasting dashboards, and quality-control models. Most manufacturers underestimate how many of these exist because they were added incrementally by different teams, often without a central record of what's running where.
2. Ask what each system can currently prove — version history, training data provenance, decision logs. Where the answer is "nothing," that's your priority list. Be specific: "the vendor said it's compliant" is not the same as being able to produce a decision log on request.
3. Separate what needs a custom build from what a vendor patch can fix. Surface-level compliance theater (a disclaimer, a checkbox) doesn't survive real evaluation; the underlying system needs actual traceability, which usually means changes to how data flows through the application, not just a new page in the admin panel.
4. Extend this thinking to customer-facing AI features, including recommendation and personalization tools. The reasoning behind Ecommerce Personalization: Using Data to Recommend the Right Products applies directly to manufacturing B2B platforms offering AI-assisted product recommendations or configuration — if it uses customer data to make decisions, it needs the same explainability standard.
5. Build the audit trail into new development from the start, rather than treating it as a phase-two addition. Every new AI feature that ships in 2026 without versioning and logging is a feature you'll eventually have to pause and retrofit.
6. Assign clear ownership. Someone specific — not "the IT team" in the abstract — should be responsible for knowing what documentation each AI system can produce and for keeping that current as systems change.

A Note on Pricing Context

Bringing AI-touching software up to a defensible, well-documented standard is a scoped engineering project, not a vague retainer. Here's how this kind of work typically maps to Scult's service tiers:

Tier	Typical scope for this scenario
Essential — $1,000	Auditing one AI-touching system (e.g., a configurator or forecasting dashboard) and identifying documentation and traceability gaps
Growth — $2,000	Rebuilding or extending a specific AI feature with proper versioning, logging, and explainability built in
Enterprise — $4,000+	Full audit and rebuild across multiple AI-touching systems, including vendor integration review and long-term architecture for ongoing compliance

These are starting points reflecting typical scope, not fixed quotes — actual cost depends on how many systems are involved and how fragmented the existing setup is. A manufacturer with a single AI-driven configurator and a clean codebase will land toward the lower end; one juggling several vendor integrations across forecasting, quality control, and a customer portal, with no existing documentation, should expect a scope closer to Enterprise.

Key Takeaways

• The European Commission's push to expand AI model-evaluation capacity, targeting operational status by 2027, shifts AI compliance from self-reported claims to independently testable standards.
• Manufacturing companies are particularly exposed because AI now runs across predictive maintenance, forecasting, and customer-facing configurators — often without built-in traceability.
• Documentation, model versioning, and decision audit trails need to be architected into software now, not retrofitted under pressure later.
• Third-party AI vendors should be scrutinized for their own evaluation-readiness, since their gaps become your risk.
• Custom-built systems give manufacturers the flexibility to add explainability and audit logging that rigid, template-based platforms often can't support.
• Treat 2026 as the build window — the cost of getting ahead of this is a scoped project now, not an emergency rebuild in 2027.

Getting AI-touching systems into audit-ready shape is a concrete, scopeable piece of work, and it's easier to plan well before the deadline than to react to it. If you want help figuring out where your current setup stands and what needs to change, book a meeting with our team.

Frequently Asked Questions

What exactly is the European Commission expanding in 2026?

The Commission is expanding the EU's technical capacity to independently evaluate AI models, aiming for that infrastructure to be operational by 2027. This means the ability to test models directly rather than relying solely on self-reported compliance from the companies deploying them.

Does this apply to all AI use, or just certain types of models?

The evaluation push is broadly aimed at AI models used across the EU, and evaluation capacity tends to focus first on higher-impact and higher-visibility use cases. Manufacturing applications like predictive maintenance, forecasting, and customer-facing AI tools fall well within that scope.

Is this a new law manufacturers need to comply with immediately?

No — this is about building evaluation infrastructure, not a new statute with an immediate compliance deadline. The practical implication is a runway: systems built or extended between now and 2027 should be built with future scrutiny in mind.

Why does this matter more for manufacturing than other industries?

Manufacturing has adopted AI heavily in areas like predictive maintenance, quality control, and supply chain forecasting, often through vendor tools with limited transparency into how the underlying model works. That combination of heavy adoption and low visibility is exactly what evaluation regimes are built to probe.

What does "model evaluation" actually test?

Typically things like a model's consistency across versions, its behavior under edge cases, the provenance of its training data, and whether outputs can be explained and traced back to specific decisions. These are engineering-level questions, not just legal ones.

We use a third-party AI tool, not something we built ourselves. Are we still exposed?

Yes. If your vendor can't produce documentation showing how their model behaves and what data trained it, that gap becomes your risk as the deploying company, not just theirs.

What kinds of manufacturing software are most likely to be scrutinized first?

Customer-facing AI features — configurators, B2B ordering platforms with AI-assisted recommendations, and quoting tools — tend to draw attention first simply because they're visible externally. Internal tools like forecasting dashboards are less visible but not exempt.

What does "traceability" mean in practical software terms?

It means being able to show which version of a model produced a given output, what data informed that output, and being able to reconstruct that history on demand rather than reconstructing it after the fact from scattered logs.

How is this different from data privacy compliance we already handle?

Data privacy governs what data you collect and how you use it. Model evaluation is about the AI system's behavior itself — its accuracy, consistency, and explainability — which is a related but distinct set of requirements.

What's the realistic cost of getting one AI-touching system audit-ready?

It depends heavily on how the system was originally built, but auditing a single system and identifying documentation gaps typically falls in Scult's Essential tier around $1,000, with a rebuild to add proper versioning and logging usually landing in the $2,000 Growth range.

How long does it typically take to bring one AI feature up to an auditable standard?

Timelines vary by system complexity, but a scoped audit-and-fix project for a single feature is usually measured in weeks rather than months, provided the underlying system doesn't need a full rebuild.

What happens if we do nothing and wait until 2027?

You risk facing evaluation scrutiny on systems that were never built to produce documentation, which typically means an expensive, rushed retrofit under time pressure rather than a planned build.

Does this affect small and mid-sized manufacturers, or only large enterprises?

It affects any manufacturer deploying AI-driven software, regardless of size. Smaller manufacturers are often more exposed in practice because they're more likely to rely entirely on third-party tools without in-house technical oversight.

Should we stop using AI features until this is clearer?

No — the more practical approach is to build or retrofit AI-touching systems with traceability and explainability from the outset, rather than pausing adoption altogether.

What's the first step if we don't know how many AI systems we're running?

Start with an inventory: list every internal and customer-facing system that uses AI in any decision-making capacity, then assess what documentation each one can currently produce.

Can our existing legacy systems be retrofitted, or do they need to be rebuilt?

It depends on the system's architecture. Some legacy platforms can have logging and versioning added incrementally; others, particularly rigid or heavily customized older systems, are often more cost-effective to rebuild than patch.

How does custom software development specifically help here?

Custom development lets you architect audit logging, model versioning, and explainability directly into the system's design, rather than working around the constraints of an off-the-shelf platform that wasn't built with those needs in mind.

What role does our website play in this, beyond internal tools?

If your website includes AI-assisted product configuration, quoting, or recommendation features, it's a customer-facing system that carries the same evaluation exposure as any internal AI tool — arguably more, given its visibility.

What is "explainability" in the context of an AI model?

It's the ability to describe, in specific and verifiable terms, why a model produced a particular output — not just that it did, but based on what inputs and logic.

Do we need to retrain our AI models to comply with this?

Not necessarily. In many cases the gap isn't the model's accuracy but the documentation and logging around it — you may not need to retrain anything, just build proper tracking around what already exists.

What if our AI vendor refuses to share model documentation?

That's a meaningful signal about the risk you're carrying. It's worth building contractual requirements around documentation access into vendor agreements going forward, and considering custom-built alternatives for critical systems.

Does this evaluation push apply only to companies headquartered in the EU?

It applies to AI models and systems operating within the EU market, which includes manufacturers based elsewhere but selling or operating within Europe.

How should we prioritize which systems to fix first?

Start with customer-facing systems and anything influencing safety-relevant decisions like quality control or predictive maintenance, since those carry the highest visibility and impact if something goes wrong.

What does an "audit trail" look like for an AI-driven forecasting tool?

At minimum, a record of which model version generated a given forecast, what data fed into it, and enough logging to reconstruct that decision path later if asked.

Is this related to the EU AI Act generally?

It's part of the broader EU effort to make AI governance enforceable in practice rather than only on paper, of which the European Commission's evaluation-capacity expansion is one concrete piece.

Can we handle this internally, or do we need outside help?

It depends on your internal engineering capacity. Many manufacturers don't have dedicated AI governance engineering expertise in-house, which is where a scoped external build or audit becomes more efficient than assembling that capability internally from scratch.

What's the risk of ignoring this until a regulator asks?

Reconstructing documentation and traceability after the fact, under time pressure, is substantially more expensive and disruptive than building it in from the start.

Does using a well-known AI platform (like a major cloud provider's model) protect us automatically?

Not automatically. Using a reputable provider can help with baseline model quality, but you're still responsible for documenting how you've configured, fine-tuned, and deployed that model within your own systems.

How does this affect procurement decisions for new manufacturing software?

It's worth adding documentation and explainability requirements to vendor evaluation criteria now, rather than treating them as an afterthought once a system is already in production.

What's the difference between Essential, Growth, and Enterprise tiers for this kind of work?

Essential typically covers auditing a single system, Growth covers rebuilding or extending one AI feature with proper logging built in, and Enterprise covers a full audit and rebuild across multiple systems including vendor review.

Will this evaluation capacity actually be ready by 2027, or could it slip?

Specific timelines for government infrastructure projects can shift, but the direction is clear regardless of exact dates — building toward evaluation readiness now is a reasonable hedge either way.

What if our AI features are very simple, like basic product filters?

Simple rule-based filtering is generally lower risk than machine-learning-driven recommendations or predictive models, but it's worth confirming which category your actual system falls into rather than assuming.

How does personalization on our site relate to this trend?

If personalization features use customer data to drive AI-based recommendations, they carry the same explainability expectations as any other AI-driven decision system.

Should we document our AI systems even if evaluation isn't operational yet?

Yes — building documentation now, while it's a planned project rather than a reactive scramble, is significantly less costly and disruptive.

What's a realistic first deliverable from an audit engagement?

A clear inventory of AI-touching systems, an assessment of what each can currently prove about its behavior, and a prioritized list of gaps to close.

Does this apply to AI used purely for internal analytics, not customer-facing?

Internal-only systems carry lower visibility risk but aren't exempt, especially if they inform decisions with downstream safety or commercial impact, like production scheduling or quality thresholds.

How do we know if our current software vendor is prepared for this?

Ask directly what documentation, versioning, and audit logging their platform supports for any AI features, and whether they can produce that documentation on request.

Is there a way to test our own systems before regulators do?

An internal audit, ideally by a team with software engineering expertise rather than only legal or compliance staff, is the most practical way to surface gaps before external scrutiny does.

What's the biggest mistake manufacturers make with AI compliance readiness?

Treating it purely as a legal or policy question rather than a software architecture question — the actual traceability and explainability have to be built into the code, not just described in a policy document.

Can this work be done alongside other software projects, or does it need to stand alone?

It's often most efficient to fold traceability and documentation work into planned software updates or rebuilds, rather than running it as a separate isolated project.

What happens to AI features that can't be made explainable at all?

Some highly opaque models may need to be replaced with more transparent approaches, particularly for high-impact decisions where explainability is non-negotiable.

How does this affect B2B manufacturers differently from B2C ones?

B2B manufacturers often have AI-assisted quoting and configuration tools that directly influence commercial terms, which tends to draw more scrutiny than consumer-facing recommendation features.

Will smaller manufacturers be able to afford compliance-ready systems?

Scoping the work incrementally — starting with an audit at the Essential tier before committing to a larger rebuild — makes this manageable for smaller manufacturers rather than requiring a large upfront investment.

What's the relationship between site speed and AI feature reliability?

Both reflect the same underlying quality of engineering — a system built carelessly for speed often has the same gaps in logging and traceability that would show up under compliance scrutiny.

Should we involve our legal team, our engineering team, or both?

Both — legal can interpret regulatory direction, but only engineering can actually build the traceability, versioning, and documentation the evaluation regime will look for.

What's a good starting point if we're not sure where to begin?

An honest inventory of every AI-touching system paired with a straightforward audit of what each one can currently prove is the most practical starting point.

How often should this kind of audit be repeated?

Given how quickly AI features get added incrementally, an annual review is a reasonable baseline, with additional checks whenever a new AI-driven feature is deployed.

Can Scult help with both the audit and the rebuild?

Yes — Scult's Custom Software Development work covers both auditing existing AI-touching systems and rebuilding them with proper versioning, logging, and explainability built in.

What should we ask a development partner before hiring them for this work?

Ask specifically how they'll implement model versioning, data provenance tracking, and decision logging — vague assurances about "compliance-ready" software without specifics are a warning sign.

Is 2026 really the right time to start, or can this wait?

Given that a 2027 operational target leaves a limited runway, and that retrofitting is more expensive than building it in from the start, 2026 is a sensible window to begin rather than wait for more regulatory detail.