Cloud-first won the last decade on merit. Centralise the data, run the intelligence at scale, return answers anywhere. For most workloads that bargain holds, and pretending otherwise would be dishonest.
The bargain bends when the data behind a decision is regulated. Once a scan checks a batch record, a procurement lot or an export declaration, where the check executes stops being an implementation detail and becomes a governance decision. That is the fork between cloud-first and in-boundary intelligence.
The two models move in opposite directions
Cloud-first moves data toward intelligence. Product records upload to a vendor platform, decision logic runs in the vendor's environment, and answers return over the network. In-boundary moves intelligence toward data. A runtime deploys inside your perimeter, policy arrives as encrypted instructions, records stay where they are, and results release only under the access your policy grants. Everything else in the comparison follows from this difference in direction.
Where cloud-first genuinely wins
Speed to start is the clearest win. An account and an API key can have codes resolving the same week, while an in-boundary deployment involves your infrastructure team, your security review and your change calendar. For a pilot measured in weeks, that difference can be decisive. That trade sits against us in every fast pilot, and we knew it when we built the product.
Elasticity is the second. GS1's Sunrise 2027 initiative expects retail point-of-sale systems to scan 2D codes alongside EAN and UPC barcodes by the end of 2027, which points at consumer scan volumes arriving in spikes nobody schedules. A hyperscale platform absorbs a festival-season surge without you provisioning a single server. Pooled learning is a third advantage: a vendor observing traffic across many customers meets a new fraud pattern before any single deployment would.
If your product data is public anyway, a catalogue of SKUs with marketing pages behind them, take the cloud offer. It is cheaper to run and faster to adopt.
Where the model breaks
Suppose a pharmaceutical exporter's consignment is held at a port and an inspector scans a carton. Under cloud-first, the answer depends on a vendor platform in another jurisdiction: its uptime, its routing, its custody of the batch record it consults. Under in-boundary, the answer comes from a runtime the exporter governs, consulting a record that never left its infrastructure. The scan is the same. The chain of accountability behind it differs at every link, and connectivity compounds the difference: a validation that waits on an internet round trip inherits every failure mode of the network between the checkpoint and the cloud.
Three failure lines repeat across regulated deployments.
- Custody. Uploading records makes the vendor a processor of them, while regulators continue to hold you answerable by name.
- Audit scope. Every sub-processor in the vendor's chain joins your audit: agreements, questionnaires, breach notification paths, evidence requests.
- Residency. Data localisation regimes constrain where regulated records may travel, and multi-tenant platforms route data on their own economics.
None of these is a feature gap a future release can close. They follow from the direction the data travels.
The direction the data travels sets the size of the audit.
The hybrid most regulated teams land on
The standing objection to in-boundary is that it forfeits cloud economics. The answer is to split the control plane from the execution plane. secQR, the DBTEZ product intelligence system, runs on KEZEL®, whose rule is short: move the work, not the data. Policies and configuration are managed centrally and travel into the boundary as encrypted instructions. Validation, product records and the tamper-evident audit trail stay inside, on your data centre, your cloud tenancy, or an isolated tenancy we manage.
The split preserves what each side does best. Central management keeps policy consistent across sites and versions. Local execution keeps decisions available when the network is unreliable.
What flows outward is your call. Aggregate analytics and anomaly patterns can be shared under policy when pooled learning is worth it to you, or they can stay home. The elasticity question narrows to the public-facing edge, where consumer scan traffic scales, while record validation stays beside the record it checks.
The deciding test fits in one exercise. Picture the audit request that asks for every system that touched your batch records in the past year. Write the list under each architecture. One list holds your infrastructure and your named team. The other adds a vendor platform, its sub-processors and every jurisdiction between you and them. Choose the list you are prepared to read out to a regulator.