A legacy application with an LLM endpoint is still a legacy application. The model simply reaches the constraints faster.

AI application modernization is now a concrete architecture problem: the model layer can evolve faster than the software underneath it.

That is becoming a practical problem for technology leaders. Microsoft, citing Forrester’s Q1 2026 Cloud and AI Application Modernization Survey, reports that 91% of IT leaders see application modernization as necessary for enabling AI advances in their business. Gartner now tracks AI-Augmented Code Modernization Tools as a dedicated market category, with capabilities spanning code and architecture analysis, dependency mapping, business-rule extraction, migration planning, refactoring, and code transformation.

The direction is clear: AI is moving into the modernization workflow itself. The harder decision remains human. Which parts of the application should stay, which should move, which should change, and which are no longer worth preserving?

For CTOs and product leaders, that choice matters more than the specific coding agent.

Why AI changes the application modernization decision

Modernization used to be framed mainly around cloud migration, infrastructure cost, end-of-life runtimes, and developer productivity. Those drivers still matter. AI adds another one: can your application safely expose the data, actions, and business logic that AI systems need?

AWS is already treating “agentic readiness” as part of continuous modernization. Its 2026 modernization tooling assesses repositories for issues such as obsolete frameworks and dependencies, while also evaluating whether applications are suitable for interaction with AI agents. Google Cloud’s migration guidance similarly separates rehost, replatform, refactor, re-architect, and rebuild because each path changes a different layer of the system.

That distinction is useful. A company can have modern infrastructure and still have an application that is difficult to integrate with AI. Moving a monolith from a private server to a cloud VM may remove hardware constraints, but it does not automatically create clean APIs, observable workflows, controlled permissions, reliable data contracts, or modular business capabilities.

Before choosing a modernization path, we look at five questions:

1. Is the existing business logic still valuable?
2. Can the current system be tested well enough to change it safely?
3. Is the main constraint infrastructure, code quality, architecture, or the product workflow itself?
4. What data and actions will AI need to access?
5. What is the acceptable blast radius if a migration or AI integration fails?

Those answers usually point toward one of four routes.

Choose the modernization path by the constraint

Replatform when the business logic works but operations are the bottleneck

Replatforming changes the environment around an application with relatively limited changes to the code. Microsoft’s Cloud Adoption Framework describes it as moving workload components to managed platform services when the goal is to reduce operational overhead or improve reliability without full redevelopment.

This route makes sense when the application still does its job, but the team is spending too much time maintaining servers, patching runtimes, managing databases, or handling capacity manually.

Typical examples include:

• moving a self-managed database to a managed database service;
• containerizing a stable application;
• replacing manually operated infrastructure with managed cloud services;
• upgrading supported runtimes while preserving core behavior.

For AI projects, replatforming can remove infrastructure friction quickly. It is often enough when the application already has usable APIs, reliable data boundaries, good authentication, and a testable codebase.

The trap is assuming that cloud hosting alone makes an application AI-ready. If the model still needs to call brittle internal functions, scrape inconsistent data, or depend on undocumented side effects, the bottleneck has simply moved.

Refactor when technical debt is slowing every new capability

Refactoring changes the internal structure of the code while preserving the application’s intended behavior.

The 2026 Microsoft modernization guidance recommends refactoring when technical debt is reducing development velocity or when code is poorly aligned with cloud practices. AWS makes the same problem visible from another angle: its codebase-analysis tooling focuses on hidden dependencies, dispersed business logic, and missing documentation because these issues tend to surface late and make modernization riskier.

Refactoring is usually the right direction when:

• releases are slow because every change touches several unrelated modules;
• business rules exist in code but are poorly documented;
• automated tests are weak or absent;
• a few tightly coupled components create most production incidents;
• the application needs new APIs, event flows, or observability before AI can interact with it safely.

AI-assisted modernization tools can help here. They can analyze large repositories, generate documentation, identify dependencies, propose code changes, and automate parts of version or framework upgrades. AWS reported in June 2026 that its Transform service had processed 7 billion lines of code and estimated 2 million customer hours saved.

Useful numbers, but they do not remove the need for engineering judgement. An agent can propose a transformation. Someone still has to decide whether the target architecture fits the product, security model, operating constraints, and future roadmap.

Re-architect when the system boundaries are the problem

Sometimes the code is maintainable, yet the architecture makes new capabilities expensive.

A common example is a large application where customer data, permissions, billing, reporting, and operational workflows share the same deployment boundary and database model. Adding an AI assistant to that environment is not just a model-integration task. The assistant needs controlled access to specific business capabilities, auditable actions, predictable failure handling, and observable execution.

Re-architecting is justified when the existing boundaries block those requirements.

That can involve extracting services from a monolith, introducing an API layer, moving toward event-driven communication, separating read and write models, or creating a dedicated integration layer for AI and external systems.

Microservices only help when the new boundaries match how the business actually needs to change.

Rebuild only when preserving the old system costs more than preserving its behavior

Rebuild is the most expensive and disruptive route, and it is often proposed too early.

Google Cloud’s current migration guidance positions rebuild for cases where the existing application no longer meets requirements, is too costly to migrate through other approaches, or depends on technology that should no longer be carried forward.

We would add one more condition: the team must be able to describe the business behavior that cannot be lost.

This is where many rebuilds get into trouble. Old systems often contain years of exception handling, operational shortcuts, customer-specific rules, and quiet integrations that never made it into formal requirements. Rewriting code without recovering that behavior can produce a cleaner system that is less useful than the old one.

AI can accelerate reverse engineering, but the work still needs traceability. AWS’s 2026 modernization approach explicitly focuses on extracting business rules and linking generated requirements back to source locations and execution paths. That is the right principle even when different tools are used.

What selective modernization looks like in practice

One of our Allmatics projects is a good example of why the answer is often smaller than a rebuild.

A content provider needed to add AI-driven translation, summarization, and content generation to an existing platform. Instead of replacing the core product, we built a separate AI-powered microservice hosted in the cloud and connected it to the existing system through an API.

Discovery took one week. Development and testing took one month, followed by two weeks of fine-tuning and one week for deployment. According to the project results, content creation and translation became three times faster, while operational costs fell by more than three times.

The important architectural decision was the boundary. The existing product continued to do what it already did well. The new AI capability was isolated, testable, and deployable as a separate service.

We have seen the same principle in older systems. In a verified Clutch review, a healthcare client described bringing Allmatics into a web portal that was only about 30% complete. The team continued from the existing codebase rather than discarding it, automated patient enrollment and results workflows, and helped shift the organization from fax-heavy processes toward online enrollment. The client reported faxed orders falling from almost 90% to 20%, with online enrollment reaching 80%.

Different technologies, same lesson: preserve useful behavior, change the layer that is creating the constraint.

A practical modernization sequence before adding AI

For most established applications, we would not begin with “Which AI tool should we use?” We would begin with a short technical and product assessment.

A useful sequence is:

1. Map the application, dependencies, data flows, business-critical rules, and external integrations.
2. Define the AI use case in operational terms: what data it reads, what actions it can trigger, and what happens when it is wrong.
3. Identify the narrowest architectural constraint preventing that use case.
4. Choose the smallest modernization path that removes the constraint: replatform, refactor, re-architect, or rebuild.
5. Add observability, permissions, rollback paths, and evaluation before increasing AI autonomy.
6. Modernize continuously instead of treating the project as a one-time migration.

That last point is becoming more important. Frameworks, dependencies, security requirements, model providers, and AI integration patterns now change too quickly for modernization to remain a once-a-decade program.

The better question is whether the application can keep changing without every new capability becoming a risky project.

Where Allmatics fits

Allmatics works with companies that already have a product, codebase, data, or connected hardware and need to move to the next technical stage without losing the business logic that made the system valuable.

Depending on the constraint, that can mean cloud modernization, API and integration work, refactoring or re-architecting an existing application, building a new service around the current platform, or developing a custom AI/ML component.

If your AI roadmap is moving faster than the application underneath it, start with a modernization map: what to keep, what to change, what to isolate, and what to retire.

That is a much better place to start a build.

The post AI Application Modernization: Refactor, Replatform, Rebuild appeared first on Allmatics.

On 20 July 2026, the European Commission switched the Digital Product Passport Registry on and opened a testing environment for businesses. The timing matters because the DPP has moved from a policy concept to working infrastructure. Retailers, brands, manufacturers, importers, distributors, and marketplaces now have something concrete to design against.

The first mandatory deadline is not tomorrow. Certain categories of large batteries are scheduled to require a Digital Product Passport from 18 February 2027, while other product groups will follow through sector-specific rules. But the architecture work starts earlier, because the DPP depends on product identifiers, structured data, access rules, APIs, versioning, and reliable ownership of information across systems.

For retail teams, that is the practical point. A Digital Product Passport may be reached through a QR code or another data carrier, but the hard part sits behind the scan.

What changed in July 2026

Three steps landed within one week.

On 14 July, the European Commission adopted harmonised standards for Digital Product Passports under the Ecodesign for Sustainable Products Regulation. Six standards are already referenced across areas including unique identifiers, interoperability, data carriers, APIs, data exchange protocols, and data storage.

On 16 July, Commission Implementing Regulation (EU) 2026/1778 set the operational arrangements for the DPP Registry. The regulation covers registration, access management, user verification, storage requirements, and the technical architecture of the Registry.

Then, on 20 July, the Registry and its testing environment went live.

The Registry does not hold the complete detailed passport for every product. The Commission describes it as an indexing layer: it stores unique identifiers, registration data, and high-level metadata, while the detailed product information remains decentralised. Businesses can register through a secure user interface or through an API, which means DPP registration can be connected to existing product and compliance workflows instead of being handled as a separate manual task.

That API option is where retail architecture starts to matter.

A DPP is only as reliable as the systems feeding it

Retail product information rarely lives in one place.

A PIM may own titles, descriptions, images, and commercial attributes. ERP may hold supplier, purchasing, and accounting data. WMS or inventory software knows stock and warehouse movements. PLM may contain material and manufacturing information. E-commerce platforms publish the customer-facing catalogue. Separate compliance files can sit in document repositories, supplier portals, or spreadsheets.

A DPP adds another requirement: the business must know which system owns each required data point and how that information is kept current.

If product composition changes, which system records the new version? If a supplier updates a material declaration, how does that flow into the passport? If the same SKU exists in three commerce systems, which identifier maps to the regulated product? If access rights differ for a consumer, a repairer, a customs authority, and a recycling partner, where are those rules enforced?

Those are data architecture questions.

The Commission’s current DPP model reinforces that direction. The Registry includes machine-readable data models and documented APIs, while the wider passport framework is built around interoperability rather than a single central database.

For retailers, the useful mental model is a product data service with regulatory responsibilities attached to it.

The retail DPP architecture has five practical layers

1. Product identity

Every passport begins with a stable identifier.

The identifier needs to map the physical product, its relevant model or variant, and any additional level required by the applicable product-specific legislation. The data carrier on the product or packaging then resolves to the correct digital information.

That sounds simple until one product is represented differently in ERP, PIM, WMS, a marketplace feed, and a distributor catalogue

Before implementing a DPP, teams should map the identifiers already in use and define which one becomes the common reference across systems. Creating another parallel ID without that mapping only adds another reconciliation problem.

2. Data ownership

Each passport field needs an owner.

Product composition may come from PLM or a supplier. Repair instructions may be maintained by service teams. Compliance documents can come from legal or quality functions. Retail attributes may be enriched in PIM. Availability and commercial data may live elsewhere entirely.

A useful DPP data map should answer four things for every field:

– source system

– accountable owner

– update trigger

– validation rule

Without that map, the passport can be technically valid and still contain stale or contradictory information.

3. A DPP service layer

Most established retailers will not want every operational system talking directly to the EU Registry.

A dedicated integration or service layer can collect the required data, normalize it, apply validation rules, create the passport payload, handle updates, and keep the external registration process separate from the internal systems of record.

This is also where teams can manage schema changes as product-specific requirements evolve. The DPP rollout is progressive, so the data required for batteries, textiles, iron and steel, furniture, or ICT products will not be identical

The architecture should expect variation rather than hard-code one universal passport.

4. Registry integration

The live DPP Registry supports both a user interface and API-based registration.

For a company with a small number of regulated products, manual registration may be acceptable at first. For large catalogues, frequent product updates, or multiple markets, API integration is the more realistic path.

The integration needs more than a single successful POST request. Teams should define retry behaviour, validation failures, registration status, proof of registration, logging, and what happens when an internal product update cannot be accepted externally.

The least glamorous part of the project is usually the most important: exception handling.

5. Access, history, and audit

A DPP serves several audiences.

Consumers may need product, repair, safety, or circularity information. Repairers and recyclers may need operational details. Authorities need compliance access. Some product data may be public, while other data can be restricted by role and applicable legislation.

The system therefore needs access rules, change history, and a defensible audit trail.

When a value changes, the business should be able to answer who changed it, which source supplied it, what version was published, and when the external passport was updated.

That is especially important once DPP data starts feeding marketplaces, after-sales services, repair workflows, and resale ecosystems.

Online retail makes DPP access part of the product page

The European Commission states that, where products are sold at a distance, online marketplaces will need to make applicable Digital Product Passports accessible.

That creates a frontend requirement as well as a compliance requirement.

For in-scope products, the product detail page should be able to resolve the correct passport from the same identifier model used by the physical data carrier. The page should not rely on a manually uploaded PDF or a copied snapshot that can drift from the current passport.

A customer may reach the DPP before purchase from an online product page, after purchase by scanning a code, or later through repair and resale services. Those paths should resolve to the same underlying product identity and current information.

For omnichannel retailers, DPP readiness becomes another test of whether the product catalogue is genuinely shared across channels or only looks shared at the interface level.

What retail teams can do in the next 90 days

A useful starting point is to find out whether the current product data can support a DPP implementation.

Here is a practical readiness sequence.

1. Map exposure by product category. Identify which products you manufacture, import, distribute, or sell that are likely to fall under upcoming DPP requirements. Confirm the relevant role your company plays for each category.

2. Inventory the data. List the information that already exists across ERP, PIM, PLM, WMS, supplier systems, document repositories, and commerce platforms. Mark the gaps and duplicate sources.

3. Assign ownership. Decide which system and team own each important data field. If two systems can overwrite the same value, resolve that before building the passport flow.

4. Map identifiers. Document how SKU, GTIN, internal product IDs, model numbers, supplier IDs, and any regulated identifiers relate to each other.

5. Use the Registry testing environment. The Commission has made a test environment and user guidance available. Run one narrow product flow through it before designing a large integration.

6. Design updates, not only first registration. Products change. Supplier data changes. Documentation gets revised. Build for versioning, validation, and controlled updates from the start.

7. Put DPP access into the commerce journey. For affected products, plan how the passport will appear on product pages, mobile experiences, after-sales flows, and physical data carriers.

This work creates a useful by-product even before a deadline arrives: a cleaner map of product data ownership.

 What our retail delivery work suggests

Allmatics has already seen the cost of fragmented retail data in a different context.

In one retail automation project, product listings had to flow to distributors through XML exports, warehouse teams needed reservation and transfer workflows, courier services were connected through APIs, and payment and notification functions had to work inside the same operating model. The central engineering problem was making several systems agree on the same product and order reality.

DPP projects bring a different regulatory scope, but the integration pattern is familiar.

A strong implementation will usually avoid duplicating product data into a new compliance silo. It can establish clear ownership in the systems that already run the business, then add a controlled layer that validates, transforms, publishes, and audits the passport data.

That is also why product discovery matters here. Before choosing a platform or starting API work, teams need a map of product categories, source systems, identifiers, ownership, access rules, and update events.

Otherwise, a DPP project can become another database that needs to be reconciled with everything else.

The decision to make now

The DPP Registry is live. The testing environment is live. The first mandatory product deadlines begin in 2027, and the framework will expand progressively across more categories.

Retail teams can prepare without rebuilding the entire stack.

The more useful question is whether the stack can identify one product consistently, assemble its passport from trusted data, publish through an API, update safely, and show the right information to the right user without a manual reconciliation step.

If the answer is unclear, that is the work to start now.

At Allmatics, we help retail and e-commerce teams map product data flows, design integration layers, and build the web, mobile, and backend services needed to connect existing systems without forcing a full replatform.

Frequently Asked Questions

Is a Digital Product Passport mandatory for every retail product in 2026?

No. The DPP is being introduced progressively through product-specific EU legislation. Certain batteries are the first group with a mandatory date in February 2027, while other categories follow on separate timelines.

Does the EU Registry store the full Digital Product Passport? 

No. The Commission describes the Registry as an indexing service that stores unique identifiers, registration data, and high-level metadata. Detailed passport information remains decentralised.

Can DPP registration be automated? 

Yes. The live Registry supports registration through a secure user interface and through an API, allowing companies to integrate the process with existing systems.

Do e-commerce and marketplace teams need to care about DPP access?

Yes, when they sell products covered by applicable DPP legislation. The Commission states that for distance selling, online marketplaces will need to make the relevant DPP accessible.

The post Digital Product Passport Retail Readiness: Architecture Guide 2026 appeared first on Allmatics.

A barcode scanner can complete thousands of reads during a shift and still leave the manufacturer with almost no understanding of what happened around those reads.

Which devices were used most heavily? Which barcode types caused repeat attempts? Did one warehouse lose time because of battery degradation, poor connectivity, or an application problem? Which units are approaching maintenance?

Hardware alone rarely answers these questions. It records an action. The software layer gives that action context.

That distinction matters more in 2026 because logistics hardware is moving into connected operating environments. Gartner describes physical AI as the combination of AI models, IoT sensors, robotics, and automation systems that support real-time sensing, analysis, and execution across warehouses, transportation, and manufacturing.

The 2026 MHI Annual Industry Report, developed with Deloitte and based on responses from more than 500 supply chain leaders, found that 56% of organisations expect to increase spending on supply chain innovation. More than half plan to spend over $1 million, while 17% expect to spend more than $10 million. The report’s harder point is that buying technology is not enough. Results depend on how well companies integrate and operationalise it across connected, real-time networks.

For manufacturers of rugged mobile computers, scanners, printers, sensors, telematics units, and warehouse equipment, the product boundary has shifted. Customers still care about scan speed, drop resistance, battery life, ingress protection, and repairability. They also expect visibility, remote control, integration, and evidence that the device improves an operational process.

A stronger casing can extend the life of a device. A software layer can extend the life of the product line.

What the software layer actually includes

For logistics hardware, it usually includes several connected components:

• an application on the device or at the edge;
• secure device identity and configuration;
• telemetry on usage, errors, battery condition, connectivity, and performance;
• APIs or middleware connecting the device to WMS, TMS, ERP, inventory, or customer systems;
• a cloud or on-premise platform for storage, management, and analytics;
• dashboards for operations, support, and product teams;
• update, access-control, audit, and vulnerability-management processes.

Not every product needs all seven. A handheld scanner may begin with an Android application and a web dashboard. A fleet telematics unit may require edge processing, event streaming, and integrations with route-planning and maintenance systems.

The architecture depends on the use case. The business logic is consistent: the device becomes more useful when its data can be interpreted, managed, and connected to the customer’s workflow.

Zebra’s June 2026 warehouse guidance makes the same practical point. Warehouse modernisation works when rugged devices are intentionally connected to intelligent software platforms. With the right software, devices can also gain new workflow capabilities without waiting for a full WMS replacement.

Why a better device eventually reaches a ceiling

1. The manufacturer cannot see how the product is used

A device can be technically reliable while being poorly matched to the real workflow.

Perhaps one model performs well with standard barcodes but causes repeated attempts with damaged labels. Perhaps a unit advertised for a full shift loses capacity after months of cold-storage use. Perhaps customers deploy devices in ways the product team never anticipated.

Without telemetry, product decisions depend on support tickets, periodic customer calls, and isolated field reports. Those inputs tend to capture the loudest problems, not the most frequent patterns.

A software layer can show usage by device, user, site, shift, barcode type, application version, or task. It gives the manufacturer a clearer answer to a basic product question: what is the hardware actually doing after it leaves the warehouse?

2. Support remains reactive

When support has no access to device status, every incident begins with reconstruction.

What model is affected? Which operating-system build is installed? Was the device online? Did the scan engine fail, or did the application reject the data? Is the issue limited to one site?

Remote diagnostics, logs, fleet status, and controlled updates reduce that ambiguity. They also help separate hardware defects from application, network, and workflow problems.

This does not remove the need for field service. It makes field service less blind.

3. The device is disconnected from the operational system

A successful scan has little value if the resulting data is entered into the wrong record, delayed in a queue, or passed to another system without context.

The software layer decides what happens after the beep:

1. Validate the barcode.
2. Associate it with a user, location, order, asset, or shipment.
3. Apply the relevant business rules.
4. Update the operational system.
5. Confirm the action to the employee.
6. Retain an auditable event.

This is where hardware begins to affect inventory accuracy, picking, receiving, traceability, maintenance, and customer service.

The need for that chain is becoming more visible as identification standards evolve. The GS1 2D Barcode Playbook released in 2026 explains that the migration to richer barcodes requires more than compatible scanners. Middleware, ERP, inventory, fulfilment, and analytics systems may all need updates to process batch, serial, expiry, and product-version data.

Reading the code is one task. Making the data operational is another.

4. Product differentiation becomes easy to copy

Hardware specifications converge. Competitors can source similar processors, scan engines, screens, radios, and enclosures. Price and availability then carry more weight.

A software platform creates a harder-to-copy layer around the device:

• historical performance data;
• customer-specific workflows;
• integration templates;
• fleet-management tools;
• analytics;
• administrator roles;
• APIs;
• update and support infrastructure.

These capabilities reduce the amount of work customers must perform around the hardware.

They can also support subscriptions for analytics, fleet management, premium support, benchmarking, or workflow modules. The exact model depends on the market, but recurring value requires recurring utility.

A real example: adding analytics to rugged scanning hardware

Allmatics worked with a UK company that manufactures rugged mobile devices for logistics and warehousing. The client wanted to add a web and mobile system capable of collecting and analysing barcode-scanner usage.

The company had no in-house software development team. Before committing to the product, it needed enough technical clarity to understand whether the idea was feasible, what the system would require, and how quickly an MVP could be delivered.

The project started with a two-week discovery phase. A seven-person team then built the initial software in approximately two and a half months, followed by testing on the client’s devices.

The MVP included:

• an Android application for barcode scanning and data collection;
• a web application for analytics and user management;
• a server environment;
• a Product Requirements Document;
• device-agnostic comparison of scanning performance.

The platform tracked activity by device, user, and day. It could surface scanning frequency, commonly used barcode types, scan timing, device-utilisation patterns, and comparative performance across scanners.

The collected data also created a foundation for maintenance planning, including closer monitoring of operating hours and battery life cycles.

The decisive outcome was the change in the client’s product. The company moved from selling rugged equipment with limited visibility after deployment to offering hardware supported by usage analytics and a customer-facing software experience.

Discovery took two weeks. The MVP was ready in roughly three months.

There are no public figures showing a specific revenue increase or percentage reduction in downtime, so we will not manufacture one. The confirmed result is narrower and still commercially relevant: the software component increased the product’s utility and gave customers operational data they did not previously have.

Read the full Allmatics barcode-scanning analytics case study.

Five capabilities worth designing first

Hardware companies sometimes begin with a long feature list. A stronger starting point is a small set of capabilities connected to actual operational decisions.

Device identity

Every event should be attributable to a known device, model, configuration, software version, location, and, where appropriate, user.

Without reliable identity, fleet analytics quickly becomes questionable.

Event capture

Define the events that matter before collecting everything.

A scan, failed scan, reboot, battery-health change, connectivity loss, configuration update, or unusually long task may each support a different decision.

Integration contracts

Decide how the platform will exchange data with customer systems.

APIs, webhooks, message queues, batch files, and offline synchronisation all have a place. The choice should follow the customer environment, connectivity constraints, and required response time.

Operational dashboards

A dashboard should answer a role-specific question.

A warehouse manager needs different information from a support engineer or product owner. One screen filled with every available metric usually creates more searching, not more clarity.

Lifecycle controls

Connected hardware requires update policies, access control, logs, support periods, and vulnerability handling.

Under the EU Cyber Resilience Act reporting rules, obligations for actively exploited vulnerabilities and severe incidents begin on 11 September 2026. Manufacturers must be able to detect, assess, and report security issues affecting products with digital elements.

A product that cannot be monitored or updated becomes harder to support as its installed base grows.

Build, buy, or integrate?

A hardware company does not need to build every component internally.

Commodity capabilities such as identity providers, infrastructure monitoring, mobile-device management, and cloud storage can often be purchased.

Customer systems such as WMS or ERP should usually be integrated rather than recreated.

The parts worth building are those that encode product knowledge or create differentiated customer value.

For a scanner manufacturer, that may include device-level telemetry, performance benchmarking, scan-quality analysis, and workflows tuned to its equipment.

For a sensor company, it may be edge logic, calibration management, alerting, and domain-specific analytics.

A useful test is simple: would customers notice if this capability were replaced by a generic tool?

When the answer is no, buying may be sensible. When the capability carries your product logic, customer experience, or data advantage, it deserves more control.

Signs that the product has outgrown hardware-only thinking

Common signals include:

• customers ask for a dashboard, API, or remote configuration;
• support cannot diagnose issues without screenshots and serial numbers;
• product teams receive little data from deployed units;
• each enterprise customer requires a separate integration;
• customers compare devices mainly on purchase price;
• firmware and application versions are difficult to track;
• data is available on the device but not usable by operations;
• the company wants recurring revenue but has no recurring product capability.

Several of these together usually point to a product architecture problem.

The device is the beginning of the system

The logistics market still needs reliable hardware. Warehouses are physical environments, and devices must survive drops, dust, cold, long shifts, unstable connectivity, and hurried users.

Yet the value of that hardware increasingly depends on what happens around it.

Gartner’s 2026 supply-chain trends place real-time sensing, analysis, and execution in the same operating model. MHI’s findings point toward connected software and physical systems. Zebra’s warehouse guidance puts rugged devices and intelligent software platforms in the same modernisation plan.

For a logistics hardware manufacturer, the practical question is which decisions the product should help customers make, which workflows it should connect, and which data should remain useful long after the scan.

That is the software layer worth building.

Planning a software layer for an existing logistics device?

Allmatics helps logistics and hardware companies evaluate product ideas, define architecture, and build web, mobile, cloud, and embedded systems around physical products.

A focused discovery should clarify the users, core workflows, integration boundaries, technical risks, MVP scope, and realistic delivery plan before the company commits to full development.

Explore our custom logistics software development experience or contact the Allmatics team to discuss your product.

The post Why Logistics Hardware Needs a Software Layer appeared first on Allmatics.

On July 21, 2026, Microsoft and Mistral announced a multibillion-dollar expansion of their partnership. The agreement adds European GPU capacity, brings more Mistral models into Microsoft Foundry and Copilot Studio, and supports deployments ranging from the public cloud to fully disconnected environments.

For European enterprises, especially those operating in healthcare, manufacturing, finance and public infrastructure, the announcement addresses a real concern: how to use capable AI models without losing control over sensitive data and essential operations.

The Microsoft–Mistral announcement arrives as the European Union continues investing in AI Factories and AI Gigafactories. Europe wants more compute capacity, more regional model development and less dependence on infrastructure controlled elsewhere.

That matters.

But an uncomfortable detail often gets lost in the discussion: a model running in Europe does not automatically give a company control over the product built around it.

The server location answers one question. The software architecture answers the rest.

Can the company replace the model without rebuilding its application? Can it move workloads between the cloud, a private environment and local infrastructure? Does it control the prompts, business rules, retrieval logic and evaluation data? What happens when an external API changes its pricing, limits or terms?

Those decisions sit inside the codebase.

Sovereign AI Architecture Goes Beyond Data Residency

Data residency is usually the first issue discussed in a sovereign AI project. It determines where information is stored and processed, which legal frameworks may apply and whether a workload can leave a particular jurisdiction.

For some systems, that is enough. A low-risk internal writing assistant may work perfectly well through a managed API hosted in an approved region.

The picture changes when AI touches patient records, operational infrastructure, proprietary manufacturing data, financial decisions or customer-facing workflows.

In those cases, control has several layers:

• Data control: where source data, prompts, logs and embeddings are stored.
• Model control: which models can be used, customized, replaced or deployed privately.
• Application control: who owns the workflow, permissions, interfaces and business logic.
• Operational control: whether the system can continue working during a network failure, provider outage or service restriction.
• Commercial control: whether the economics remain viable when usage, token prices or licensing terms change.

A company can satisfy the first layer and remain heavily exposed across the other four.

For example, an AI application may use a European cloud region while depending on a provider-specific agent framework, proprietary vector storage, closed evaluation tools and model-specific prompts spread across the application. Moving the workload later may require a substantial rewrite.

The infrastructure is regional. The dependency is still deep.

Where AI Vendor Lock-In Actually Hides

Most teams do not deliberately create vendor lock-in. It develops gradually.

A proof of concept starts with one API call. The test works. Then the team adds retrieval, document parsing, tools, memory, user permissions and an admin panel. Six months later, the AI provider is woven through the entire product.

The dependency usually appears in four places.

1. Model-specific application logic

Different models handle prompts, tool calls, structured outputs, multimodal inputs and context windows differently.

When model-specific instructions are written directly into backend services, switching providers becomes a software migration rather than a configuration change.

Even a small difference in output structure can affect downstream validation, reporting or user interfaces.

2. Proprietary retrieval infrastructure

Retrieval-augmented generation often involves document ingestion, chunking, embeddings, vector storage, metadata filters and ranking.

If each component is tied to one vendor’s formats and APIs, the company may technically own its documents while losing practical control over the system that makes those documents usable.

This becomes especially painful when a business has already processed millions of records.

3. Workflow logic inside external platforms

Low-code agent platforms are useful for testing ideas. Problems appear when approval rules, exception handling, integrations and operational knowledge remain inside a platform that cannot be reproduced elsewhere.

The model may be replaceable. The workflow is not.

4. Logs and evaluation data

Production AI requires more than application logs.

Teams need to understand which prompt was used, what context was retrieved, which model responded, what tools were called, how much the request cost and whether a human corrected the result.

That history becomes one of the most valuable assets in the system. It helps improve prompts, compare models, investigate errors and prove how a decision was produced.

When this information exists only inside a provider dashboard, the company loses part of its own operational knowledge.

The Software Layer Is the Part a Business Can Own

A model will change. Prices will move. Better providers will appear.

The durable asset is the software layer around the model.

That layer includes the company’s data structures, integrations, access rules, workflow logic, interfaces, review processes and operational history. It contains the parts that reflect how the business actually works.

This distinction has shaped several projects at Allmatics.

In one content-processing project, the client needed to introduce AI into an existing platform without rebuilding the core product. The Allmatics team developed a separate AI microservice hosted in a cloud environment and connected it to the client’s system through an API.

According to the AI-powered content optimization case study, the resulting workflow reduced operational costs by more than threefold and accelerated content production.

The important architectural choice was separation.

The original platform remained responsible for the business process. The AI capability operated through a defined service boundary. Prompts, processing logic and future model changes could be handled inside that service without forcing the client to rebuild the main application.

That pattern is useful far beyond content generation.

A separate AI layer can support:

• several model providers;
• private and cloud-based models;
• model selection based on task or sensitivity;
• centralized access policies;
• prompt versioning;
• caching and cost limits;
• fallback rules;
• unified monitoring.

The provider can change while the business workflow remains stable.

A Model Is Only One Component of an AI Product

Document processing offers a clear example.

An organization may describe its need as “using AI to process documents.” In practice, the model handles only part of the work.

The full system may need to receive files, identify their type, extract text, detect tables, validate required fields, structure the data, flag uncertain results, route exceptions to a human and export the final output into another system.

Allmatics applied this broader product approach while developing DocStreams, an AI-powered resume processing platform.

The platform converts unstructured PDF resumes into standardized, structured documents. Its value depends on the complete workflow: file processing, data extraction, formatting rules, validation and export.

A newer OCR model could improve extraction quality. It would not replace the product.

This is why ownership of the workflow matters. When the application logic belongs to the business, individual AI components can be tested and replaced as the market develops.

When the workflow belongs to a provider, every model decision becomes a platform decision as well.

Regulated Industries Need Control at the Workflow Level

Healthcare systems make the distinction even clearer.

A clinical AI assistant may use a strong medical model, but the model alone cannot manage patient access, consent, clinical roles, audit history, document retention, integrations or human approval.

Those controls belong in the surrounding software.

In an HealthTech project, the team built an AI assistant around Google Med-PaLM 2 for private healthcare providers. The work included the wider medical workspace rather than a standalone chat interface.

The platform had to organize patient information, support clinical workflows and fit into the way healthcare professionals already worked.

Another Allmatics healthcare project shows how much impact the surrounding workflow can have even without generative AI. A medical provider relied heavily on fax-based enrollment and patient-result processes. Allmatics completed and extended its web portal, automated key operations and built custom enrollment forms.

In the client’s verified Clutch review, faxed orders fell from almost 90% to 20%, while online enrollment reached 80%.

The result came from redesigning the process around software. A model alone could not have produced it.

The same principle applies when AI is introduced. The organization needs control over where data moves, who can access it, how results are reviewed and what happens when the model is unavailable or uncertain.

For that reason, sovereign AI architecture becomes particularly relevant in healthcare, aviation, industrial systems, logistics and other environments where continuity and traceability matter.

What a Vendor-Neutral AI Architecture Looks Like

There is no universal architecture for every AI product. A sensible design starts with the workload, the data and the level of risk.

Still, several patterns make future changes less painful.

Keep models behind an internal AI gateway

The application should call a company-controlled service rather than communicate directly with several model providers.

That service can standardize requests and responses, apply access rules, select the appropriate model and record usage.

A customer support request may go to a fast managed model. A sensitive document may be processed by a private model. A low-confidence response may be sent to a second model or a human reviewer.

The application does not need to know every implementation detail.

Store business logic outside prompts

Prompts are useful, but they should not become the only place where process rules exist.

Validation requirements, permissions, approval thresholds and exception handling should remain visible in the application layer. This makes the system easier to test, audit and maintain.

A prompt can instruct a model to return a structured answer. The backend should still verify whether that answer satisfies the required schema and business rules.

Control the data pipeline

Document ingestion, preprocessing, metadata, retention and deletion rules should be designed as first-class parts of the product.

This gives the organization a clear map of where information enters the system, how it is changed and where it is stored.

It also makes future migration more realistic. The company can regenerate embeddings, change a vector database or introduce a new retrieval method without losing the source data and metadata needed to rebuild the index.

Build observability into the product

Production teams need their own operational record.

At minimum, they should be able to trace:

• the user or system that initiated a request;
• the model and version used;
• the prompt or prompt version;
• the retrieved context;
• tool calls and external actions;
• latency and cost;
• validation results;
• human corrections.

This information helps engineering teams compare models and troubleshoot failures. It also gives product owners a more honest view of where AI contributes value and where it creates extra work.

Design for more than one deployment mode

Microsoft and Mistral are explicitly supporting cloud, cloud-connected and fully disconnected deployments. That range reflects how different enterprise workloads have become.

Some tasks require cloud scale. Others require local processing because of latency, confidentiality or service-continuity requirements.

A portable application layer allows an organization to use both.

For example, a system may process sensitive source data locally, send anonymized content to an external model and store the final operational record in the company’s own environment.

The right boundary depends on the process. It should be decided deliberately, before production usage makes the existing design expensive to change.

Sovereign AI Architecture Does Not Mean Running Everything On-Premises

Private infrastructure brings control, but it also brings cost and responsibility.

The organization must provide compute capacity, deployment pipelines, security updates, monitoring, model maintenance and staff capable of operating the environment.

For many ordinary workloads, a managed cloud model remains the practical choice.

A good architecture leaves that choice open.

It allows the company to keep low-risk, high-volume tasks in a managed environment while moving selected workloads to a private cloud, local infrastructure or edge device.

Allmatics supports secure on-premises data processing, private AI development and custom AI/ML systems. The starting point, however, should be the business constraint rather than a preference for one deployment model.

Questions worth asking include:

• Which data cannot leave the organization?
• Which workflows must continue during an internet or provider outage?
• Which workloads require predictable latency?
• What level of model customization is needed?
• How quickly does the model need to improve?
• What operational capacity does the company have internally?

For one company, sovereign architecture may mean a fully disconnected system. For another, it may mean a provider-neutral application running across several managed services.

Both can be valid.

Can Your Company Actually Move Its AI?

A simple architecture review can reveal whether an AI product is portable or only appears portable.

Ask five questions:

1. Can we replace the primary model without rewriting the core business workflow?
2. Do we know where prompts, logs, embeddings and evaluation data are stored?
3. Does the AI capability have a defined service boundary and internal API?
4. Can selected workloads move to a private or local environment?
5. Can essential parts of the product continue operating when an external AI service is unavailable?

Three or more negative answers usually indicate a structural dependency.

That dependency may be acceptable for a prototype. It becomes harder to justify once the AI system handles customer data, influences business decisions or supports daily operations.

Where Allmatics Fits

Sovereign AI creates demand for infrastructure, models, legal frameworks and security controls. It also creates a large software engineering problem.

Someone still needs to build the application that connects company data, AI models and operational workflows.

Allmatics develops custom AI and software products across healthcare, HRTech, retail, logistics, aviation and other data-intensive industries. The work can include:

• AI architecture and product discovery;
• model integration and orchestration;
• custom web and mobile applications;
• private and hybrid AI deployment;
• document-processing pipelines;
• ERP, CRM, EHR and ATS integrations;
• role-based access and approval workflows;
• monitoring, audit logs and human review;
• modernization of existing platforms.

The aim is straightforward: keep the business process under the client’s control while allowing individual models and infrastructure components to evolve.

For teams moving an AI feature from pilot to production, an architecture review is often the useful first step. It maps model dependencies, data flows, integration risks and the components that should remain portable or private.

Talk to our AI/ML development team about the software layer behind your AI product.

FAQ

What is sovereign AI architecture?

Sovereign AI architecture is a system design that gives an organization defined control over its AI data, models, application logic, deployment environment and operational processes. The required level of control depends on the workload and regulatory context.

Does sovereign AI require an on-premises deployment?

No. A sovereign architecture can use public cloud, private cloud, local infrastructure or a hybrid model. The key issue is whether the organization understands and controls where data is processed, how the system operates and how easily components can be changed.

How can custom software reduce AI vendor lock-in?

Custom software can place models behind an internal API, keep workflow logic outside provider platforms, store logs and evaluation data under company control and support multiple models or deployment environments. This makes future migration more manageable.

The post Sovereign AI Architecture: Build Systems You Control appeared first on Allmatics.

If you run a retail platform, a commerce backend, or anything that touches checkout, agentic commerce has already arrived, even with a human still confirming most orders. The real question is narrower. Can your systems hand a purchase decision to software you don’t control, verify what that software was authorized to do, and still trust what comes out the other end?

From recommendation engines to agentic commerce

Retail AI used to stop at the suggestion. A recommendation widget surfaced a product, a chatbot answered a question, and a person decided what happened next. Agentic commerce removes that last step, at least in delegated scenarios. Once a shopper has pre-approved a merchant, a spending limit, and a timeframe, the agent doesn’t need a new approval for every routine purchase. It compares prices across sellers, checks the approved budget, and completes the transaction within those limits.

Adobe’s most recent traffic data shows why this stopped being a niche behavior. AI-referred traffic to US retail sites rose 393% year over year in the first quarter of 2026, TechCrunch reported. That traffic converted 42% better than regular traffic in March 2026, a full reversal from March 2025, when AI traffic converted 38% worse. Those AI-referred shoppers also spent 48% more time on site and generated 37% more revenue per visit. These visitors tend to arrive further along in the decision process than shoppers from traditional channels. That’s still AI-assisted discovery rather than fully delegated purchasing. But it shows a meaningful part of the shopping journey has already moved into AI interfaces, and retailers are starting to build for that reality instead of treating it as a dashboard curiosity.

Salesforce just made it official

On July 6, 2026, Salesforce took Agentforce Commerce out of pilot and into general availability. Treat that date as a signal more than a product update. The Shopper Agent now carries a customer from discovery through checkout on a retailer’s own storefront. The Buyer Agent handles B2B orders over WhatsApp and SMS without a portal login. The Merchant Agent runs back-office catalog and promotion work in plain language instead of a rules engine.

The distribution move matters more than the feature list. Salesforce confirmed native integration into ChatGPT this same month. Google Search’s AI Mode and the Gemini app follow later in the summer. That means a shopper’s AI agent, running in an interface a retailer doesn’t own, can complete a purchase on that retailer’s storefront directly. Salesforce has reason to move fast here. According to its own holiday season data, retailers running their own shopper agents grew sales 59% faster than retailers that sat out. AI-referred traffic converted at roughly eight times the rate of social traffic. When a platform this size ships this fast, “watch this space” stops being the right response.

Two sides of agentic commerce: buying and retail operations

Salesforce’s own product split is a useful map here. Shopper Agent works the customer-facing side: search, cart, checkout. Buyer Agent handles B2B ordering. Merchant Agent runs catalog and promotion work behind the scenes. Those are two different problems. Customer-facing agentic commerce is about a shopper’s agent finding and buying a product, still with a confirmation step in most flows today. Agentic retail operations is about a retailer’s own systems making decisions autonomously, on pricing, inventory, and storefront content, without a customer in the loop at all. Three patterns matter most on that operational side: dynamic pricing, autonomous inventory decisions, and session-level storefront personalization.

Dynamic pricing is the clearest case. A traditional pricing system runs on fixed rules: match a competitor minus 5%, hold a margin floor, open a promotional window on schedule. An agentic pricing system continuously optimizes price within predefined margin, compliance, and promotion guardrails, using live competitor, demand, and inventory signals instead of a static rule set.

Inventory management is where the dollar figures get concrete, and it’s the pattern with the clearest production evidence. Walmart reports that its Self-Healing Inventory system automatically reroutes overstock to the stores that need it, before the surplus becomes a write-off. It has saved the company more than $55 million so far. Walmart is now extending the system beyond the US into Costa Rica, Mexico, and Canada.

Personalized storefronts are the least visible pattern, but arguably the highest-leverage one where it’s deployed. An agentic system doesn’t work from pre-built customer segments. It rebuilds page layout, product order, and promotional content for each session in real time, and no marketer approves each configuration individually.

The agentic commerce architecture problem hiding underneath

Most omnichannel builds solved a coordination problem: keep the cart synced between mobile and desktop, match an in-store promotion to the website. That got fixed at the interface layer. The backend systems underneath, point of sale, ERP, warehouse management, CRM, mostly stayed separate. They only needed to look consistent to a human shopper. Nobody required them to talk to each other in real time.

Agentic commerce breaks that assumption. An agent making a pricing call needs live inventory data. An agent rebuilding a storefront needs current margin data by SKU. When those systems don’t share a common data layer, the agent acts on stale or incomplete information. A wrong decision made instantly is often worse than a slow one.

Unified commerce is the usual architectural answer. It’s a shared, real-time operational layer that gives every channel a consistent view of products, pricing, inventory, orders, and customer data. That doesn’t always require replacing every backend system, but it does require removing the conflicting versions of truth between them. It’s the prerequisite most agentic commerce vendor demos skip past. Manhattan Associates’ 2026 benchmark covered more than 400 specialty retailers across North America, EMEA, and Latin America. Only 7% qualified as unified commerce leaders, while 33% remained in the Basic category. The leaders posted nearly twice the growth rate of the least mature retailers. That gap is the real bottleneck, not the AI model choice.

What’s actually blocking most retailers from agentic commerce

The gap isn’t primarily budget. Most retailers are blocked by infrastructure decisions made five to ten years ago, decisions that were reasonable at the time.

Legacy point-of-sale systems are the most common chokepoint. They were built to record a transaction, not to feed a real-time data layer. Pulling live sales data out of a legacy POS without a full replatform usually means middleware, custom connectors, and ongoing maintenance. Every extra layer between the source system and the agent adds latency and another point of failure.

Fragmented data is the second blocker. Customer records sit in a CRM. Inventory sits in an ERP. Web behavior sits in an analytics platform. Margin data sits in a spreadsheet finance updates monthly. Commercetools’ research on agentic commerce readiness found that 81% of retailers say data quality issues affect business decisions at least sometimes, 45% sometimes and 36% often. An agent can’t reason across data that doesn’t connect. Unifying that data has to happen before any agent goes live, not after.

The third blocker gets the least attention: authorization. Who in the organization actually approved an AI system to change a price, or cancel a supplier order? At most companies, nobody has written down what an agent is allowed to do, under what conditions, or who signs off. Without that, even technically capable systems sit in pilot mode for months, because nobody wants to be the person who flips the switch.

A commerce agent needs more than API access

Giving an agent a live data feed is the easy part. The harder part, and the part most agentic commerce coverage skips, is proving afterward that the agent only did what it was supposed to do. That comes down to four things.

Identity: which agent made the request, and on whose behalf. Authorization: what spending limit, merchant list, or category it’s allowed to touch. Execution safeguards: idempotency so a retried request doesn’t double-charge or double-order, spending caps, and a rollback path. Audit: a record of which cart got approved, by what mandate, using what data.

This isn’t theoretical. Google’s Agent Payments Protocol builds a cryptographically verifiable chain between what the shopper asked for, what got approved, and what was actually charged. An Intent Mandate captures the shopping request and its limits. A Cart Mandate records the exact items and price. A Payment Mandate carries that approval to the payment network. Depending on the flow, the shopper approves in real time or authorizes the agent to act later within those predefined limits. Either way, the chain of signed mandates leaves an audit trail: what was requested, what the agent was allowed to buy, and what was paid. OpenAI’s Agentic Commerce Protocol takes a related approach. OpenAI never becomes the merchant of record. Each delegated payment token is capped at a specific amount and expiry, tied to a specific merchant, before the retailer’s own payment processor ever sees the request. Retailers building for agentic commerce need this same kind of scoped, logged authorization layer, not just an open API. That applies whether they’re exposing a storefront to someone else’s shopping agent or running their own pricing and inventory agents.

What building a POS-connected retail platform taught us

We covered the full build of a POS-connected customer engagement platform in an earlier case study, for a US retail startup with dealer and partner networks. The short version: no unified data layer, a POS replatform that was never on the table. We built a connector architecture on .NET, AngularJS, Google Cloud, and Kubernetes instead, surfacing POS data in near real time without touching the source system.

What that project made clear applies directly to agentic commerce. Partial stock updates. Delayed POS syncs. Two channels reporting different numbers at the same time. Those are the edge cases where agentic systems either hold up or fall apart.

Handing that same connector layer to an external AI agent, rather than only to your own dashboards, adds a new list of requirements. A machine-readable product catalog the agent can actually parse. A real-time inventory endpoint instead of a nightly sync. Scoped permissions per agent rather than one shared API key. An idempotent checkout path. A defined fallback for when the POS sync lags. A log of every action an agent took and why.

Where to start if you’re not starting from zero

The retailers making real progress this year didn’t launch a company-wide transformation program. They picked a narrow scope, proved it, and expanded from there.

Start with data unification before touching any agent. Map what data exists, where it lives, and what’s missing. Build or buy the connector layer that makes POS, inventory, and customer data available in one place. Treat that as the slower, unglamorous prerequisite it actually is.

Once that layer is stable, pick the highest-value, lowest-risk use case for a first agent: dynamic pricing in one category, or demand-driven replenishment for the top-selling SKUs. Define its scope narrowly. Build the human override before launch, not after an incident forces one. Run it against a control group for 60 to 90 days, and measure the result honestly before expanding.

Gartner projects that 40% of enterprise applications will include integrated task-specific AI agents by the end of 2026, up from less than 5% in 2025. Bain estimates agentic commerce will make up 15% to 25% of total US ecommerce sales by 2030, a $300 to $500 billion market. McKinsey’s global estimate runs as high as $3 to $5 trillion by the same year.

That’s a lot of money chasing a problem most companies haven’t solved yet. Data and governance work, done early and without fanfare, is what separates the two outcomes. One retailer scales an agent. The other spends 2027 explaining why the pilot never launched.

How Allmatics approaches this

Our Web/Mobile Development and AI/ML Development work covers exactly this layer. That means connector architecture exposing POS, inventory, and customer data in real time without a forced replatform. It also means agent scoping that separates what a system can suggest from what it’s authorized to execute on its own. We wrote up the full POS-connected retail SaaS build if you want the detail behind the architecture referenced above. Our broader view on retail and e-commerce infrastructure is a useful starting point if you’re earlier in scoping this.

If you’re deciding where an AI agent should sit in your retail stack, get that decision right during product discovery. It’s cheaper than fixing it after the agent is already live against production data.

Frequently Asked Questions

What is agentic commerce? Agentic commerce is retail AI that acts on a shopper’s or a business’s behalf: comparing options, adjusting prices, managing inventory, or completing a purchase, rather than only recommending a product for a human to act on. It requires real-time data access and defined authority to execute, not just to suggest.

Is agentic commerce the same as a shopping chatbot? No. A chatbot answers questions and waits for a human decision. An agentic system takes the next step: executing a price change, a reorder, or a checkout, within limits a business defines in advance.

What does a retailer need before deploying an agent? A unified data layer connecting POS, inventory, and customer data in real time, a narrowly scoped first use case, and an explicit governance rule for what the agent can do without human approval. Skipping the data layer is the most common reason pilots stall.

The post Agentic Commerce in 2026: What Retail Systems Need Before AI Can Buy appeared first on Allmatics.

At the same time, cloud AI is not going away. Larger models still handle tasks that need broad context, complex reasoning, shared data, or more compute than a phone can provide.

That creates a more important question for mobile teams: which intelligence should run on the device, and which should stay in the cloud?

In 2026, that decision affects much more than model performance. It shapes the app’s data architecture, privacy model, offline behavior, latency, operating cost, device support, and update strategy.

The strongest AI mobile products will not choose on-device or cloud as an ideology. They will choose the right execution environment for each task.

Why the cloud-first default is no longer enough

For years, the standard architecture for mobile AI was simple.

The mobile app collected input. A backend sent that input to a cloud model. The app waited for a response and displayed the result.

That architecture still works. In many cases, it remains the correct choice.

However, it is no longer the only practical option.

Google’s current Android AI guidance explicitly separates on-device, cloud, and hybrid approaches. Its documentation points to several advantages of local inference, including offline operation, local data processing, and the absence of additional per-call inference cost for supported on-device solutions.

Google also recommends hybrid architectures when different parts of an app have different requirements. A smaller local model can handle short or privacy-sensitive tasks. Meanwhile, a cloud model can process larger documents or tasks that require more knowledge and compute.

Apple is moving in a similar direction. At WWDC26, Apple expanded its Foundation Models framework so developers can work with Apple’s on-device models, Private Cloud Compute, and external model providers through a common model interface.

The result is clear: model placement is becoming part of mobile architecture.

It is no longer just an infrastructure decision made after the product team designs the feature.

What changed for on-device AI mobile apps

The basic idea of running machine learning models on phones is not new. What changed is the range of tasks that mobile hardware and platform frameworks can now support.

In June 2026, Apple published details about its third generation of Apple Foundation Models.

The family includes two on-device models. AFM 3 Core continues Apple’s approximately 3-billion-parameter dense model line. AFM 3 Core Advanced uses a 20-billion-parameter sparse architecture and activates between 1 and 4 billion parameters for a request.

Apple also makes an important distinction: the more capable on-device model targets its most powerful Apple silicon systems. Therefore, teams still need to account for device capability and availability.

Android follows a different platform model.

Gemini Nano runs through Android’s AICore system service on compatible devices. AICore uses device hardware for inference and manages model distribution and updates at the system level.

For developers, this removes part of the operational burden of bundling and maintaining a large model inside the application itself.

The available APIs already cover practical tasks such as summarization, rewriting, proofreading, image description, speech recognition, and custom prompting.

These are no longer research demos. They are platform capabilities that product teams can evaluate during architecture and discovery.

AI-native does not mean on-device only

The term “AI-native” often gets used too loosely.

A conventional app does not become AI-native because a team adds a chat window. At the same time, an app does not need to run every model locally to qualify as AI-native.

A more useful definition is architectural.

An AI-native application treats model behavior, data access, evaluation, failure handling, and model placement as core product decisions from the beginning.

For a mobile product, that means answering several questions early:

1. What data can the AI feature access?
2. Which tasks must work without a network connection?
3. What latency will users accept?
4. Which devices must the feature support?
5. What happens when local inference is unavailable?
6. Which tasks need cloud-scale models or shared context?
7. How will the team evaluate output quality after release?
8. How can models or prompts change without breaking product behavior?

These questions affect the data layer, APIs, permissions, user flows, telemetry, and fallback logic.

Therefore, the local-versus-cloud decision should happen during product discovery and architecture design. It should not wait until a team starts optimizing an already finished feature.

On-device AI improves privacy, but it does not solve privacy by itself

Privacy is one of the strongest reasons to consider local inference.

When a task runs entirely on-device, input data does not need to travel to a remote inference endpoint. Android’s documentation, for example, describes how Gemini Nano processes prompts locally and how AICore isolates requests.

However, local inference alone does not make an application private.

The application may still send analytics events. It may sync generated outputs to the cloud. Backups, logs, crash reports, third-party SDKs, and account synchronization can also move data away from the device.

Therefore, teams need to map the complete data flow.

For each AI feature, the architecture should clearly define:

• what data enters the model;
• where inference happens;
• what gets stored;
• what gets logged;
• what leaves the device;
• which services receive that data;
• how long the system retains it.

This distinction matters for products that process health information, messages, voice, location data, personal documents, or biometric signals.

On-device processing can reduce unnecessary data movement. Still, privacy depends on the complete system, not only the location of the model.

Why agents change the mobile architecture problem

On-device inference is only one part of the current shift.

The other is agentic behavior.

A normal AI feature generates an answer. An agent can use tools and execute a sequence of actions toward a goal.

According to Gartner’s 2025 forecast, up to 40% of enterprise applications may include integrated task-specific AI agents by the end of 2026.

That forecast covers enterprise applications broadly, not mobile apps specifically. Still, the architecture questions become particularly important on personal devices.

A mobile agent may interact with messages, files, calendars, contacts, location, camera input, or other applications. As a result, teams need stricter boundaries than they would for a simple text-generation feature.

The product architecture should define what the agent can read, which tools it can call, and when it must ask for confirmation.

It should also separate reversible actions from irreversible ones.

For example, drafting a message and sending a message are not the same operation. Finding an available calendar slot and booking a meeting are also different levels of authority.

In practice, many agentic mobile products will use hybrid orchestration.

A local component can handle private context, fast classification, or permission checks. Meanwhile, a server-side model can manage heavier planning, external integrations, or shared workflow state.

The right split depends on the task. However, the boundary must be explicit.

Where teams get the on-device and cloud split wrong

One costly mistake is deciding the architecture too late.

Suppose a team builds every AI feature around synchronous server requests. The app’s authentication, data flow, error handling, and user interface will all reflect that assumption.

Later, the team decides that part of the feature should run locally.

At that point, the change may affect much more than one API call.

The team may need to redesign caching, state synchronization, request contracts, feature availability, testing logic, observability, and fallback behavior.

The opposite mistake also happens.

A team may push too much processing onto the device because local inference sounds cheaper or more private. However, Android’s own guidance notes that on-device models can be less capable than cloud alternatives and require compatible devices.

Device constraints also vary.

Inference speed depends on hardware. Some platform models are available only on supported devices. Custom models may introduce their own storage, memory, battery, and delivery requirements.

Therefore, “run everything locally” is not a serious architecture strategy.

Neither is “send everything to the cloud.”

The useful question is narrower: what is the best execution environment for this task?

A practical framework for on-device AI mobile apps

Most architecture discussions become easier when teams evaluate each AI capability separately.

1. Does the feature need to work offline?

If yes, the product needs local functionality.

That does not always mean the entire AI workflow must stay on-device. A smaller local model may provide a reduced feature set, while a cloud model handles more complex requests when connectivity returns.

The key is to define offline behavior deliberately.

A product should not discover its offline experience only after users lose connection.

2. Is the task latency-sensitive?

Camera, voice, typing assistance, live translation, and interactive editing can suffer when every action waits for a network round trip.

For these tasks, local inference may provide a better interaction model.

However, teams should measure real performance on target devices. “On-device” does not automatically mean “instant.”

Hardware still matters.

3. Does the task process sensitive data?

When users reasonably expect data to stay private, local processing deserves serious consideration.

Messages, personal documents, voice recordings, images, and health-related signals are obvious examples.

Still, teams must review the entire data lifecycle. Local inference has limited value if application logs or analytics later transmit the same sensitive content elsewhere.

4. Does the task need broad context or a more capable model?

Some workloads clearly favor cloud inference.

A task may need a large context window, access to enterprise data, shared state across devices, external tools, or a model that cannot run effectively on target phones.

In those cases, forcing the workload onto the device can reduce quality without creating meaningful user value.

The cloud has a clear role.

5. How often will the model or behavior change?

The update path matters.

Android’s AICore manages Gemini Nano distribution and future updates at the system level. Other local models may use different delivery mechanisms. Cloud models, meanwhile, can change independently from the mobile application release.

Therefore, teams should decide how often they expect the model, prompts, tools, or policy layer to change.

A fast-moving AI feature may need a different architecture from a stable offline capability.

6. What happens when one side of the architecture is unavailable?

Hybrid systems need explicit fallback rules.

What happens when the device does not support the local model?

What happens when the cloud service times out?

Can the user continue with reduced functionality? Should the app queue the task? Does the feature disappear entirely?

These are product decisions as much as technical ones.

The team should make them before implementation.

Development tools are getting faster, but architecture still matters

The way teams build mobile applications is also changing.

In May 2026, Google introduced the ability to build native Android applications in Google AI Studio.

Developers can generate Kotlin-based Android projects from prompts, use an embedded Android Emulator, install builds on a physical device, and publish builds to an internal Google Play testing track.

This can shorten prototyping and initial scaffolding.

However, faster code generation does not remove the difficult parts of production development.

Teams still need to make decisions about security, data architecture, model evaluation, permissions, offline state, backend integration, observability, testing, and long-term maintenance.

As development becomes faster, poor architecture can also become faster.

That makes early technical decisions more important, not less.

Native and cross-platform decisions need a new evaluation layer

The native-versus-cross-platform discussion also changes when a product includes local AI.

A shared codebase can still make sense. However, teams should evaluate the actual AI workload before selecting the platform strategy.

Questions include:

• Does the feature depend on a platform-specific AI framework?
• Which devices support the required model?
• Does the application need direct access to hardware acceleration?
• Will iOS and Android use the same model?
• Does each platform need different fallback behavior?
• How much native integration will the shared framework require?

There is no universal answer.

For some products, a cross-platform application with thin native AI integrations will work well.

For others, deep platform-specific capabilities may justify more native development.

The decision should follow the product requirements.

How Allmatics approaches mobile AI architecture

At Allmatics, we treat model placement as an architecture decision, not a feature-level implementation detail.

Our Web and Mobile Development and AI/ML Development work connects product requirements with the system that needs to support them.

During discovery, the key questions are practical.

What must work offline? Which data should remain local? What latency does the user experience require? Which devices must the product support? Where does a cloud model provide enough additional value to justify the network and infrastructure dependency?

From there, the architecture can define clear boundaries between device processing, cloud inference, backend services, and external tools.

For agentic applications, the same principle applies to permissions and actions.

The system needs clear rules for what an agent can access, which actions require confirmation, where context lives, and which operations belong on the device or server.

This work should happen before the core data flow becomes difficult to change.

The real shift is architectural

On-device AI is becoming more capable, but that does not mean every mobile application should move its AI stack onto the phone.

The more useful shift is architectural.

Mobile teams now have a wider set of execution options. They can run some tasks locally, keep others in the cloud, and combine both approaches in one product.

That flexibility is valuable. It also creates more design decisions.

Teams that make those decisions early can build cleaner data flows, better offline behavior, more predictable costs, and stronger privacy boundaries.

Teams that postpone them often discover that moving inference later means changing the application around it.

For on-device AI mobile apps in 2026, the central question is no longer whether a phone can run useful AI.

The question is where each part of the intelligence should run, what data it should access, and how the complete system should behave when conditions change.

The post On-Device AI Mobile Apps in 2026: Architecture Guide appeared first on Allmatics.

On June 11, 2026, something quiet but consequential happened across the EU. Member states had to designate their notifying authorities. These bodies certify who can assess connected products under the Cyber Resilience Act (CRA). No press conference, no dramatic headline. Just the first domino in a regulatory sequence. It will reshape how companies design, ship, and maintain connected hardware and embedded software sold into the EU.

Does your roadmap include anything with a chip, a sensor, or a firmware update mechanism? Think industrial controllers, fleet telematics, medical-adjacent monitoring equipment, smart retail hardware, wearables, or connected vehicles. If so, the CRA applies to you. It doesn’t matter where your company is headquartered or where you manufacture the product. The obligation attaches to placing the product on the EU market, full stop. That’s according to the European Commission’s Cyber Resilience Act overview.

A staggered deadline, not a single cliff edge

The CRA doesn’t arrive all at once. That’s exactly why so many product teams are underprepared: there’s no single date forcing urgency. The timeline breaks into three real milestones. By June 11, 2026, Member States had to put conformity assessment infrastructure in place. September 11, 2026 is the one every embedded team should mark on its calendar. From that date, manufacturers must report actively exploited vulnerabilities within 24 hours of discovery. The report goes to ENISA and the relevant national CSIRT. A full notification follows within 72 hours. A final report is due within 14 days, as TechTimes reported when the 24-hour vulnerability clock was announced. Then December 11, 2027 brings full compliance across the essential cybersecurity requirements of the regulation. Non-compliance carries fines of up to €15 million or 2.5% of global annual turnover.

Eighteen months sounds comfortable. It isn’t, once you map it against how teams build embedded products in practice.

Why most embedded and IoT teams aren’t ready

Four gaps show up again and again in connected-product organizations, and none of them are quick fixes.

Start with the paper trail. Embedded stacks accumulate third-party libraries, RTOS components, and vendor SDKs over years of development. Most teams can tell you what’s in the current firmware release, but not much before that. Very few can produce a complete, versioned bill of materials across every product still in the field. That’s exactly what a 24-hour vulnerability disclosure clock demands, per ArmorCode’s CRA requirements guide.

Then there’s the update problem. A CRA-compliant product needs a secure, authenticated over-the-air update path for its full support lifetime. Much of today’s fielded hardware never anticipated that need. Engineers assumed firmware would rarely, if ever, change after shipment. Retrofitting OTA into a product line that lacks it takes real engineering work, not a quick patch you bolt on later.

Incident response is the third gap, and it’s the one teams underestimate most. Reporting a vulnerability to ENISA within 24 hours assumes three things are already in place. You need monitoring that can detect exploitation. You need an escalation path that doesn’t depend on one engineer answering their phone. And you need disclosure templates drafted before you need them. Most embedded teams have never run this drill, because until now nothing forced them to.

The fourth gap sits outside engineering entirely. Most embedded products depend on components such as chipsets, modules, RTOS distributions, and third-party SDKs. Most companies never asked those suppliers for a security attestation or a patch commitment. Few even have a reliable contact for vulnerability disclosure. The CRA makes the integrator responsible for the security posture of everything in the bill of materials. That includes parts they didn’t write a single line of code for. Supplier contracts and procurement criteria need updating alongside the engineering work. That’s a conversation most product teams haven’t had yet with their hardware vendors.

The retrofit problem: products already in the field

Teams can architect new product lines for CRA compliance from the start. The harder question is what happens to everything already shipped. Think of the industrial controllers, fleet trackers, and connected hardware sold over the last five to ten years. Much of it is still under warranty or still generating revenue through service contracts. Engineers never designed a lot of that installed base with an OTA update path, let alone a signed one. That means “just push a patch” isn’t an option without a hardware or firmware architecture change.

Products with long field lifecycles face a real strategic decision. Industrial, aerospace, and maritime hardware routinely runs for ten years or more. Teams can retrofit a secure update mechanism into the current generation. They can accept a defined end-of-support date and communicate it to customers. Or they can manage the compliance gap through compensating controls, such as network segmentation or managed monitoring. That buys time until the next hardware revision ships. None of these options are free. The right choice depends on unit count in the field and how much runway remains before December 2027. The teams handling this best are mapping their installed base against the CRA’s requirements now. There’s still time to choose deliberately rather than react.

The compliance surface is also getting bigger, not smaller

This lands at an inconvenient moment. Enterprise IoT is moving past the pilot phase into what analysts now call “autonomous connected operations.” That means more devices, more autonomy, and more data flowing between machines with less human review in the loop. That’s according to IoT Analytics’ State of Enterprise IoT 2026 report. Every device added to a fleet is one more entry in the SBOM and one more endpoint that needs an update path. It’s also one more thing to track once a vulnerability disclosure clock starts ticking. Growth and compliance debt are compounding at the same time. That’s exactly why teams can’t treat this as a document-writing exercise handed to legal in Q4 2027.

What “secure by design” means in practice

For product and engineering leaders, CRA readiness breaks into work that’s genuinely architectural, not cosmetic:

CRA readiness starts with secure boot and signed firmware, so a device only runs code it has cryptographically verified. It also means encrypting and authenticating communication between devices and back-end services. That protection needs to hold not just at rest, but as data moves across the fleet. Teams need a maintained, exportable SBOM that regenerates automatically as part of the build pipeline. That beats an SBOM an engineer assembles by hand only when an auditor asks. They need a tested OTA mechanism that can push a patch to deployed hardware. No truck roll required, no asking a customer to plug something in manually. And they need an incident response runbook the team has rehearsed, not just written. That way, the 24-hour clock doesn’t start with someone reading the regulation for the first time.

None of it is exotic. It just means applying discipline earlier in the product lifecycle than most embedded roadmaps allow for.

A realistic roadmap for the next eighteen months

Teams that treat this as a single 2027 deadline tend to compress all the hard decisions into the final quarter. That’s exactly when engineering capacity is scarcest and mistakes are most expensive. A more workable sequence starts now, in the second half of 2026, with a gap assessment. That means mapping every connected product line against the CRA’s essential requirements. It means cataloguing what SBOM data already exists versus what needs reconstruction. And it means identifying which fielded products can realistically get a secure OTA retrofit versus which need a defined end-of-support date.

That assessment should feed directly into architecture decisions before any 2027 hardware revision locks its bill of materials. Retrofitting secure boot or signed firmware into a design that’s already frozen costs dramatically more than specifying it up front. Teams can build and rehearse incident response processes and monitoring in parallel, well ahead of the September 2026 reporting obligation. That way, the first real disclosure isn’t also the first time anyone has run the process. None of this requires waiting for a final compliance deadline to start. It requires treating the next eighteen months as the working window it is.

How we approach this at Allmatics

This is squarely inside the work we do in Embedded IoT Development and Tech Consulting. That includes gap assessments against the CRA’s essential requirements, security retrofits for fielded products, and OTA pipeline design. We also build the SBOM and monitoring tooling that makes a 24-hour disclosure window achievable instead of aspirational. We’ve built connected systems across aviation, maritime, and logistics hardware, and the pattern holds everywhere. The earlier security becomes a first-class requirement, not a checklist item, the cheaper compliance gets down the line.

If your product roadmap has connected hardware shipping into the EU between now and December 2027, plan ahead. The right time for a product idea evaluation that includes a CRA gap assessment is before the next hardware revision locks in. Don’t wait until regulators start asking questions.

The post EU Cyber Resilience Act for IoT: 2026 Compliance Guide appeared first on Allmatics.

SHRM’s 2025 Talent Trends survey — 2,040 HR professionals surveyed — found that 69% now use AI to support recruiting, up from 51% the year before. At the same time, Pew Research found that 66% of Americans would not want to apply for a job where AI helps make hiring decisions. That Pew finding is from 2023. By 2026, AI adoption has only accelerated — candidate trust hasn’t.

The gap isn’t a perception problem you fix with a landing page. It’s a governance problem, and it’s sitting in the middle of most companies’ hiring stacks right now.

Why recruiters are going all-in

The business case isn’t subtle. The same SHRM survey found that 89% of HR professionals using AI in recruiting say it saves time or increases efficiency. That’s hard to argue with when a team of three is filling 50 roles a quarter.

44% now use AI to screen resumes, 66% to write job descriptions. The teams doing this are sourcing faster, reaching passive candidates earlier, and spending less time on the administrative side. Whether the technology is doing what it claims is a separate question. The adoption momentum is real.

Why candidates are checking out

The trust gap has been visible for years. Pew Research found that 66% of Americans would not want to apply if AI helped make hiring decisions. That data is from 2023 — but adoption has only accelerated since, and candidate sentiment hasn’t moved in the other direction.

Gartner’s 2025 survey found only 26% of job applicants trust AI to fairly evaluate them. A Greenhouse report found 70% of hiring managers trust AI to make better decisions, while only 8% of job seekers call the process fair. 38% have already withdrawn from a hiring process specifically because it involved an AI interview.

Three things drive this. Candidates worry their data is used in ways they can’t see. They assume pattern-matching rather than judgment. And most critically, they have no idea what to do if they think the screening was wrong. There’s usually no one to ask, no rationale to read, no path to contest the outcome.

When candidates start gaming the AI

Here’s something most governance frameworks haven’t caught up with yet, and most HR professionals are only now starting to talk about openly.

Candidates have figured out how the screening works — and they’re working around it. One tactic that’s become widespread: pasting the full job description into a resume in white text. Invisible to a human reader, fully visible to an ATS or AI scanner. The system finds every keyword match, scores the candidate at or near 100%, and flags them as a top applicant. The recruiter sees a strong match, books the interview, and discovers in the room that the candidate can’t name the tools they listed as “expert level.”

The interview stage isn’t immune either. With AI tools that transcribe questions in real time and feed answers through earpieces or a second screen, some candidates are running AI-assisted interviews while the recruiter is running AI-assisted screening. At a certain point, the AI is evaluating the AI’s output. Nobody’s assessing the actual person.

This isn’t a fringe edge case. HR forums, hiring managers across sectors, and talent acquisition leads in tech and financial services are all reporting versions of this. It’s one reason some teams are bringing back structured in-person components for senior roles — not because they distrust remote hiring, but because the signal from AI-screened, AI-coached remote interviews has degraded enough that they can’t tell the difference between a strong candidate and a well-prompted one.

The deeper problem: AI screening was supposed to make it easier to find great candidates. In an environment where both sides are optimizing with AI tools, it’s getting harder, not easier, to find someone who can actually do the job.

Governance doesn’t solve this directly. But it creates the conditions for catching it: logged decisions, documented criteria, human review at defined checkpoints, and — critically — outcome tracking. Did the high-scoring candidate actually perform well six months in? Without that loop, the whole system is flying blind.

The governance gap nobody’s closing

Most companies using AI in hiring have built no decision trail. There’s no record of what the system scored, why it ranked someone low, or whether any human actually reviewed the output before the rejection email went out.

This is becoming a legal problem, not just an ethical one.

Under Regulation (EU) 2024/1689 — the EU AI Act — AI systems used for screening, filtering, ranking, or evaluating candidates can fall under Annex III high-risk use cases, particularly when they influence employment decisions in meaningful ways. This covers resume screening tools, automated interview scoring, and candidate ranking engines. When a system qualifies, mandatory requirements apply: risk management documentation, bias testing, human oversight, logging, and candidate explanation rights. Article 86 gives any candidate the right to a plain-language explanation of how an AI-assisted decision affected them.

The Digital Omnibus agreement, reached provisionally in May 2026, introduced a split timeline: stand-alone high-risk AI systems under Annex III — most recruitment and screening tools — must comply by December 2, 2027. AI embedded in regulated products under Annex I has until August 2, 2028. The direction hasn’t changed. The deferral is not permission to wait.

NYC Local Law 144 has been in force since 2023, requiring annual independent bias audits for automated employment decision tools used in New York City. Penalties start at $500 per violation and escalate daily.

Skills-based hiring as a trust bridge

One structural response is changing what the AI evaluates in the first place. Skills are 5x more predictive of job success than degrees. Skills-based criteria can reduce reliance on weak proxies like educational credentials — but only if those criteria are structured, documented, and consistently applied. The method doesn’t fix bias automatically. It removes one common source of it if implementation is serious.

Companies using structured skills-based assessment report an 89% improvement in employee retention compared to credential-weighted approaches.

85% of employers say they use skills-based hiring. Harvard Business School and Burning Glass research puts the net effect of removing degree requirements at 0.14% incremental increase in non-degree hires — meaning most companies remove the credential requirement from the job posting but leave their ATS filtering logic exactly as it was.

Real skills-based hiring changes what the AI evaluates. And when evaluation is based on demonstrated competency rather than keyword proximity, it’s also harder to game with white-text tricks or AI-generated answers, because the assessment requires evidence of actual work.

What an audit-ready HRTech architecture actually needs

Most HR teams know they should have governance on their AI tools. Fewer know what that concretely means architecturally. Here’s what it takes to build a system that holds up under regulatory scrutiny and candidate appeals:

• Data lineage. Every piece of candidate data used in a scoring or ranking decision needs a traceable origin: where it came from, when it was collected, whether the candidate consented, and what transformations it went through before the model saw it.
• Decision logs. Every AI recommendation needs to be logged with a timestamp, the model version, the input features used, and the output. These logs are what Article 86 of the EU AI Act and NYC Local Law 144 both require.
• Explainable recommendations. The system should produce a readable rationale alongside any score — not “score: 72” but “scored lower on X, Y not assessed.” Explainability is both a trust signal for candidates and a requirement under GDPR’s automated decision-making provisions.
• Human override with logging. The AI recommends. A human decides. That decision — including any deviation from the AI output — gets logged. This is the feedback loop that makes the model better over time.
• Bias and performance monitoring. Disparate impact metrics need to be tracked continuously, not just at initial deployment. Critically: outcome tracking — did the high-scoring candidate actually perform well? — is the only way to detect whether the model is degrading due to gaming or data drift.
• Access control. Who can query candidate data, who can adjust scoring logic, who can see rejection rationale — each needs to be role-scoped, logged, and auditable.

None of this requires rebuilding from scratch. But it does require an architecture review and a governance layer built on top of existing tooling.

If your product uses AI in hiring, you already need an audit

Regulation (EU) 2024/1689 applies to any system that influences employment decisions, regardless of where the vendor is headquartered. The obligations differ depending on your role in the supply chain.

If you’re a provider — building and placing an AI hiring tool on the market — you carry the full set of obligations: risk management system, technical documentation, conformity assessment, bias evaluation, post-market monitoring, and registration in the EU AI database.

If you’re a deployer — an employer or HR team using a third-party AI screening tool — your obligations are narrower but real: genuine human oversight, transparency notices to affected candidates, records of AI-influenced decisions, and a fundamental rights impact assessment if you’re using the tool at scale.

Most companies are both. An employer building a proprietary scoring tool is a provider. That same employer using a vendor’s ATS for a different part of the process is a deployer. Most HR legal teams haven’t mapped that boundary yet.

The December 2, 2027 deadline for stand-alone Annex III systems gives more runway than the original date. It doesn’t change what needs to get done.

Building AI hiring tools candidates actually trust

Four things consistently separate tools candidates trust from ones they don’t.

Transparency before the process starts. Candidates don’t need to understand the model. They need to know what factors it uses and what it rules out, before they apply. A short plain-language explanation changes the psychological dynamic considerably.

Explainable outputs. Every recommendation should have a readable rationale attached. Not “score: 67” but “scored lower on X because Y.” This satisfies Article 86 of the EU AI Act and reduces the likelihood of a candidate feeling they were dismissed by a black box.

A real appeal path. Most companies have no answer to “who do I talk to about this?” That gap creates legal exposure and erodes trust in ways that accumulate quietly.

Human override by design. The AI recommends. A person decides. That decision gets logged. This is how the system gets more accurate over time, not just how it satisfies regulators.

The HR teams going all-in on AI aren’t wrong. The candidates walking away aren’t wrong either. The companies in trouble are the ones that adopted the efficiency layer without building the accountability layer underneath it — and are now finding out, through degraded signal quality and incoming regulation, that those two things were never actually optional.

An AI audit starts with a systems inventory: every AI component in your hiring stack, what decisions it influences, what data it uses, whether any of it is documented. From there: data flows, decision point mapping, log architecture, explainability mechanisms, human oversight design, and a risk roadmap that tells you what needs to change first.

That’s a concrete technical engagement, not a compliance exercise in the abstract. Allmatics runs this kind of audit for companies building or operating AI in regulated contexts. If you want to understand what your hiring AI is actually doing and where your exposure sits, that’s where we start.

The post AI in Recruiting: Why 69% Adoption Creates New Risk appeared first on Allmatics.

That’s fine. What’s less fine is not knowing what you have.

Before your enterprise clients start sending security questionnaires with AI-specific sections. Before your investors ask about AI governance. Mapping what AI runs inside your products and operations — what it does, what data it touches, what decisions it influences — is work most companies haven’t done. That’s what an AI audit is for.

The EU AI Act adds regulatory urgency to a problem most companies already had.

The regulatory context, briefly

Regulation (EU) 2024/1689 has been rolling out in phases since August 2024. The EU banned prohibited AI practices — social scoring, real-time biometric surveillance in public spaces — in February 2025. Obligations related to general-purpose AI models became enforceable in August 2025, as outlined in the official EU AI Act implementation timeline.

As of August 2, 2026, the EU AI Office holds full enforcement powers over GPAI requirements. Article 99 of the regulation sets the penalty structure: up to €35 million or 7% of global annual turnover for deploying prohibited AI; up to €15 million or 3% for high-risk system failures; up to €7.5 million or 1% for providing incorrect information to regulators.

For high-risk AI systems, the picture shifted in May 2026. The European Parliament and Council reached a provisional agreement under the Digital Omnibus initiative to extend the Annex III deadline: December 2027 for standalone high-risk systems, August 2028 for AI embedded in regulated products. Formal adoption is pending. The extension covers high-risk obligations only — transparency disclosures and generative content labeling remain on the original schedule.

AI classification and compliance obligations depend on each system’s intended purpose, technical design, and deployment context. Where classification is uncertain, legal counsel should be involved. Allmatics works on the technical and operational side: what your systems actually do, what risks they carry, and what documentation and infrastructure would support compliance.

Which industries are most exposed

Annex III of the EU AI Act defines eight categories of AI likely to be high-risk: biometric identification, critical infrastructure management, education and vocational training, employment and worker management, access to essential services (credit, insurance, benefits), law enforcement, migration and border control, and administration of justice.

Whether a specific system falls into these categories depends on how it’s deployed and what role it plays in the decision — not just what the vendor calls it. The European Commission’s draft guidelines on high-risk classification are intended to help, though they remain subject to revision. This is where technical assessment matters as much as legal interpretation.

Financial services

AI systems that influence creditworthiness assessments, loan origination, credit limit decisions, or insurance pricing for natural persons are likely high-risk under Annex III. That includes automated affordability checks, credit scoring models embedded in lending platforms, and underwriting tools in life and health insurance. The challenge is that AI sits inside core workflows as a component in platforms organizations bought years ago, often without anyone mapping it specifically. Many teams don’t know which models run, what data trained them, or whether teams retain the outputs anywhere.

HR and recruitment

AI systems that influence who gets shortlisted, ranked, or scored in a video interview are likely high-risk. So are tools that influence performance evaluations, promotion recommendations, or task allocation. Companies using third-party HR platforms with AI-assisted features are deployers under the Act — compliance isn’t something you can push to the vendor. Article 26 of the regulation requires deployers to inform affected individuals when AI influences decisions about them and to maintain genuine human oversight: not a click-through confirmation, but a person with the authority and information to review and override.

Healthcare and e-commerce

Healthcare is where the regulatory picture gets most layered. AI that assists with diagnosis, clinical decision support, patient triage, or treatment recommendations is likely high-risk. The complication is a dual compliance framework: AI systems that also qualify as medical devices under the EU MDR or IVDR must satisfy both sets of requirements. AI-enabled medical devices that went through MDR Notified Body assessment have an extended transition period until August 2027. Purpose-built AI clinical tools that don’t qualify as medical devices don’t get that buffer. For most healthcare organizations, the first question isn’t “do we comply” — it’s “what classification applies to which tool,” and that mapping usually doesn’t exist yet.

In e-commerce and retail, the picture is more varied. Most AI — recommendation engines, personalization models, the majority of support chatbots — falls under limited risk or no-risk categories, with minimal obligations. But there are categories that catch retailers off guard: AI used to assess creditworthiness for buy-now-pay-later products is likely high-risk, as is AI that prices insurance add-ons on a per-customer basis. AI-powered profiling that feeds into access decisions for financial products can push an otherwise ordinary system into Annex III territory. Companies that assume their AI is low-risk because it’s consumer-facing may be right — or may be carrying undisclosed high-risk exposure they haven’t looked at.

For B2B SaaS companies with AI features, the exposure is often unexpected. If your product touches any of the Annex III domains — and many do, particularly in HR, finance, and operations — your compliance posture is already part of your sales story whether you’ve addressed it or not. Enterprise procurement in the EU is asking about AI governance. Companies that can answer with documented specifics are moving faster through deal cycles.

What an AI audit actually checks

A legal team can tell you what the regulation requires. They can’t tell you whether your RAG pipeline has data isolation gaps, whether your third-party LLM is receiving customer PII in prompts, or whether your AI-driven decisions are reproducible after the fact. That’s the technical side of readiness — and that’s where Allmatics works.

Inventory and model mapping

The starting point is always inventory: which AI features are actually active in your product or operations? This requires going through products, vendor agreements, and infrastructure — not asking teams to self-report. AI appears in platforms through feature updates that product managers approved without fully understanding the AI component. Companies consistently find more AI than they expected.

From there, we map models and APIs: what’s running, in-house or third-party, which APIs feed into which decisions. If you build on a foundation model — GPT-4, Claude, Gemini, or similar — the chain from API call to user-facing output matters for both data governance and accountability.

Data, logging, and risk checks

Third-party LLM exposure is where companies regularly underestimate their risk. What data do you send to external models? Does customer PII appear in prompts? Does your DPA cover how the vendor processes that data? This is where the first meaningful surprises tend to surface.

For products using Retrieval-Augmented Generation, we look at what sits in the knowledge base, who controls it, how teams scope retrieval, and whether isolation controls prevent one customer’s data from appearing in another’s responses. RAG architectures that look clean at the design level frequently have isolation gaps in production.

Logging and auditability is a consistent gap across sectors. Can you reconstruct a specific AI-driven decision after the fact — what input the system received, what it returned, what confidence indicators showed, what a human did with that output? Without this, internal review and regulatory audit are both difficult. The GPAI guidelines from the European Commission are explicit about documentation requirements. The technical infrastructure to support them is a separate matter.

Prompt injection is a live risk most organizations haven’t formally tested: can adversarial inputs manipulate system behavior in ways that affect other users or internal data? Data leakage raises a parallel question: can the model return information it shouldn’t — from training data, other sessions, or connected databases?

We also look at human review and fallback mechanisms. Does a meaningful oversight step exist before high-stakes outputs reach production? Does the system have a functional fallback when it returns low-confidence outputs or goes down? After a model goes live, does anything watch for drift, degraded accuracy, or unexpected behavior — or does the system run until someone notices something wrong?

This is the assessment a legal team can’t conduct and that most organizations haven’t done for themselves. Legal interpretation of the regulation matters, but it depends on first understanding what’s actually running.

An AI audit is not a conformity assessment

Worth stating clearly. An AI audit from Allmatics is not a formal conformity assessment, and it doesn’t produce an EU Declaration of Conformity or any official certification.

What it is: a structured readiness process. We help companies map their AI landscape, identify which systems may fall into regulated categories, surface documentation and technical gaps, and build a remediation roadmap — clarity about what you have, where the risks are, and what needs to be built or documented before formal compliance obligations apply.

Formal conformity assessment, as defined in Article 43 of the regulation, is a separate step. For most Annex III systems, companies can conduct it internally once the required documentation and processes are in place. For certain biometric AI systems without harmonized standards applied, the Act requires a third-party notified body. Allmatics helps you get to the starting line for that process.

Definitive legal classification decisions — whether a specific system is high-risk under the Act — should involve qualified legal counsel. We work alongside that process, not in place of it.

Why starting now matters more than December 2027 suggests

The extended Annex III deadline gives more time than originally planned. It doesn’t make the work smaller.

A thorough AI inventory and gap analysis takes weeks. Remediation — building out documentation, risk management systems, logging infrastructure, human oversight mechanisms — takes months. If a notified body assessment is required, that needs to be scoped and scheduled well ahead of the deadline. The conformity assessment process itself has preparation requirements that most companies are underestimating.

Research from the Cloud Security Alliance found that companies with existing AI governance practices adapted to the Act’s requirements significantly faster than those starting from zero. The compliance structure the regulation demands — documented risk management, controlled data practices, meaningful human oversight, continuous monitoring — is also just sound AI operations. Organizations that treat this as a compliance checkbox will do the minimum and stop. Organizations that treat it as a chance to understand what their AI actually does will come out ahead regardless of whether a regulator ever comes knocking.

There’s also a commercial dimension that’s harder to defer. EU enterprise procurement teams are already evaluating AI governance posture — in questionnaires, security reviews, and board-level conversations. The companies closing those deals faster are the ones that can answer those questions precisely, not with “we’re working on it.”

Allmatics helps companies understand the technical, data, product, and operational readiness of their AI systems — from initial AI inventory and risk mapping through gap analysis and remediation planning. Legal interpretation of AI Act obligations should be validated with qualified counsel where needed. To understand your current AI posture before clients or regulators start asking, reach out.

The post AI Audit for EU AI Act Readiness: What Companies Need to Check Now appeared first on Allmatics.

Over 60% of those AOG events involve failures that predictive AI systems can detect 15 to 30 days in advance. The technology to prevent most of them already exists. The gap is in how — and whether — it gets deployed.

The aviation IoT market grew to $11.03 billion in 2026, up from $9.13B the year before, a 20.8% jump driven largely by predictive maintenance deployments and real-time aircraft monitoring. That growth is happening in actual systems, not in proof-of-concepts.

The problem with maintenance by calendar

Aviation has operated on one core logic for decades: replace components on a fixed schedule based on flight hours or calendar dates. Time-based maintenance is safe in the sense that it prevents operating parts past their design life. It’s wasteful in ways the industry has quietly accepted as normal.

30 to 40% of components replaced under fixed-interval schedules still have useful life left when they come out. Meanwhile, a meaningful share of unplanned failures happen between scheduled checks — components that degraded faster than the interval assumed. The interval was designed for the average case, and the average case is not the problem.

The global MRO market stands at $85 billion, with roughly 40% absorbed by reactive, unplanned repairs. The emergency repair premium alone is 4.8 times the cost of a planned maintenance event, according to ATA MSG-3 industry cost analysis.

Condition-based maintenance asks a different question. Not “when did we last replace this?” but “what does the sensor data say about this component right now?” The first question is answerable with a spreadsheet. The second one requires embedded sensors and real-time analytics.

What the sensor layer actually does

A modern commercial aircraft generates over 1TB of sensor data per flight. Engines, APUs, landing gear, hydraulics, avionics — every major system can carry sensors tracking vibration frequency, temperature profiles, pressure, and operating hours.

Raw telemetry by itself is noise. The value comes from ML models trained on OEM baseline profiles and historical failure databases, detecting micro-anomalies weeks before they show up on a flight deck indicator. Boeing’s AnalytX fleet data puts the average advance warning at 21 days — long enough to schedule a repair at base, order parts at standard rates, and send a crew that arrives knowing exactly what they’re fixing, rather than diagnosing a mystery failure at 2 AM at an outstations airport.

Cloud-dependent architectures have a real problem in this environment, though. Satellite connectivity at cruising altitude is still intermittent. More critically, some monitoring tasks need sub-millisecond response times that a cloud roundtrip cannot deliver. Edge AI becomes less a preference and more a hard requirement.

What edge AI means on an aircraft

Edge AI means inference runs on the device, not in a remote data center. A neural processing unit (NPU) embedded in the system-on-chip handles anomaly detection locally, flags deviations in real time, and sends only relevant event data upstream — the sensor feed does not need to stream continuously to the cloud.

The hardware ecosystem has caught up. New SoCs from NXP, MediaTek, and STM32 now ship with dedicated NPU cores built for edge inference workloads. Zephyr RTOS has been gaining real traction for secure, low-power connected devices — Embedded World 2026 made clear it has become the default choice for safety-aware embedded development. For aviation environments where power budgets are constrained and failure modes matter, hardware choices compound fast.

The architecture that works in production divides responsibility deliberately: sensors capture telemetry at the component level, on-device inference runs anomaly detection and flags deviations from OEM baselines, an edge gateway aggregates events across systems, and the cloud handles model retraining and fleet-wide analytics. Edge handles speed and resilience. Cloud handles learning and scale. The boundary between them is a design decision, not a default setting.

The certification problem nobody explains well

DO-178C governs software in airborne systems. DO-254 covers hardware. Neither was written with adaptive machine learning in mind. EASA has been developing AI-specific guidance — its framework for Level 1 and Level 2 AI systems was on track for finalization through 2026 — but the certification process for any specific product still involves significant documentation overhead, traceability evidence, and time.

The practical path through this is scope definition. Predictive maintenance systems that sit in the monitoring and analytics layer — anomaly detection, alert generation, automated work order creation — rather than directly in flight-critical control paths face a much cleaner regulatory situation. They operate outside the certified avionics environment. Getting the boundary wrong early adds years to deployment timelines.

Teams that scope this correctly see real numbers. Operators running mature AI predictive programs are reporting 35% fewer unscheduled AOG events within 12 months and 18-25% lower total MRO costs compared to time-based preventive maintenance. Those results make the case internally for expanding scope over time, eventually including deeper integration with certified systems.

When embedded AI moves into the cockpit

The predictive maintenance conversation mostly stays in the MRO world: ground teams, data platforms, work order automation. But there’s a parallel track where embedded AI is taking on tasks directly alongside pilots.

The ReadU6 project is a useful illustration of what this engineering actually looks like. Built with a UK aviation client, it’s an AI-powered communication device that processes ATC instructions in real time, filters cockpit noise, and surfaces structured command text for pilots — all running on a custom embedded system built on a high-performance single-board computer, physically designed for cockpit constraints: compact, low-power, anti-glare.

The AI side ran NLP-based speech recognition and translation models trained over eight months on real ATC communication data. Getting reliable performance under noise, strict latency requirements, and safety constraints meant the hardware-software boundary was the actual engineering problem. Not the model architecture.

That dynamic is increasingly true in predictive maintenance too. The intelligence moving closer to the aircraft changes what the work is: less about which algorithm to run, more about what runs where, how it fails safely, and what the certification scope covers.

Where deployments actually stall

Sensor coverage gaps are the most common silent failure mode. A model trained on partial sensor data produces partial predictions, and partial predictions create a false sense of coverage that is arguably worse than having no predictive system at all. Mapping the actual instrumented surface area before claiming predictive capability is unglamorous work that most teams skip.

The edge-cloud boundary also needs to be an explicit architecture decision. What runs on-device, what runs on the ground gateway, what goes to the cloud — this needs to be decided deliberately, because changing it mid-project means redesigning data contracts and revalidating the inference pipeline.

And maintenance workflow integration is where ROI actually materializes. A predictive alert that generates a push notification but not a work order usually gets ignored by the time the ground team checks their inbox. Closing the full loop from anomaly detection to parts pre-order to crew assignment is where time-to-repair cuts of up to 40% show up. The analytics layer is the easy part. The workflow integration is where the money is.

If you’re mapping where to start, Allmatics works with aerospace and aviation teams on embedded IoT development and AI system integration — from product discovery through deployment. The scoping process is usually where the clearest picture of what to build first, and what to leave for later, emerges.

The post Predictive Maintenance in Aviation appeared first on Allmatics.