Regulation × Innovation

Regulation × Innovation

When the Rules Become Part of the Product

A CCC Advisory Insight on Embedded Compliance | September 2026

The Separation That is Narrowing

For much of the past decade, regulation and innovation have been treated as opposing forces, one that constrains and one that creates. Product teams built first and compliance teams reviewed afterwards, treating regulatory requirements as a gate to pass through rather than a feature to design around. That separation is narrowing, and the shift is visible across financial services, technology and increasingly any regulated product category.

The change is not that regulation has become lighter. If anything, the opposite is true, as data protection, artificial intelligence, operational resilience and financial crime regimes have all deepened in scope over the past two years. What has changed is where compliance capability sits within the product itself. Firms are no longer content to demonstrate compliance through policies, audits and after-the-fact assurance. They are building it into the architecture of what they sell, so that regulatory alignment becomes something a client or partner can see and test directly, rather than something a firm simply asserts.

Where This Is Already Happening

The pattern is particularly visible in payments and financial technology, where regulatory requirements increasingly shape how products are designed and operated. KYC, KYB, AML controls, transaction monitoring, identity verification and regulatory reporting are no longer necessarily separate processes sitting around the product. In many cases, they are being integrated directly into the technology that delivers the service.

The same logic is becoming increasingly relevant to artificial intelligence. Bringing legal, risk and compliance considerations into product design early allows organisations to make decisions about data, vendors, model use, human oversight, monitoring and documentation before those decisions become expensive to change. When compliance enters only at the point of launch, it is often being asked to review a product whose fundamental architecture has already been decided.

The regulatory direction itself increasingly reinforces this approach. The EU AI Act provides a clear example. Article 12 requires high-risk AI systems to technically allow for the automatic recording of events, or logs, over the lifetime of the system. Article 19 then requires providers to retain those automatically generated logs, where they are under the provider's control, for an appropriate period of at least six months, subject to applicable law. The significance is not simply that logging is required. It is that the requirement sits inside the technical design of the system.

An organisation cannot create a convincing policy after deployment and use it as a substitute for a system that was never capable of generating the required evidence. Where the requirement applies, the product has to be capable of producing the evidence through its own operation. That is the point at which regulation stops being something applied to a product and starts becoming part of the product.

The same direction can be seen beyond AI. The EU Cyber Resilience Act requires manufacturers of products with digital elements to consider cybersecurity risks during planning, design, development, production, delivery and maintenance. It also introduces requirements around secure-by-design products and vulnerability handling throughout the relevant support period.

The broader direction is clear: for an increasing number of digital products, security and regulatory expectations are moving upstream. They are becoming things organisations are expected to engineer into the product rather than demonstrate only after it has been built.

What This Means For Firms

The practical consequence is a change in timing and ownership. A control added once a product has shipped is a cost absorbed after the fact, typically under time pressure and often incomplete. A control designed into the product from the outset becomes part of what the organisation is offering, and increasingly part of why a client or regulator chooses to trust it.

This changes where governance and compliance functions need to sit. A function that reviews a product once it has been built is largely reviewing decisions that have already been made. A function involved during design can influence those decisions before they become difficult or expensive to change. Firms that have not yet made this shift are not simply carrying more compliance risk. They are carrying a competitive disadvantage against firms able to demonstrate, rather than assert, that trust is engineered into what they sell.

For boards, the relevant question is no longer only whether the organisation is compliant. It is whether that compliance is visible, testable and built into the product itself, in a form a client, partner or regulator could verify without relying on the organisation’s word for it.

The Governance Implications

Embedding compliance into a product's architecture does not remove the need for governance. It relocates it. When a control lived in a policy document, oversight meant reviewing that policy, tracking exceptions and auditing whether staff followed it. When the same control lives inside code, the object of governance changes. The question is no longer only whether people followed a rule, but whether a system continues to do what it was built to do, and who is checking.

This creates a timing problem that compliance language does not capture on its own. A governance committee that meets quarterly to review compliance reports is structurally mismatched to a control that runs continuously and could fail silently between meetings. Boards need to know not only that a control exists, but how its ongoing performance is monitored and how quickly a failure would surface.

It also creates an accountability problem. A policy typically has a named owner, usually someone in compliance or risk. An embedded control often does not have an owner in the same sense. It may have been designed by a product team, built by engineers, and signed off by compliance at a point in time the product has since moved beyond. Governance frameworks need to assign clear accountability for embedded controls before something goes wrong, rather than reconstruct it afterwards.

Finally, it creates an assurance problem. A claim that a product is compliant by design is itself a claim that needs testing, in the same way any other control would be tested. Governance functions should be asking who independently verifies that the embedded logic does what the organisation says it does, how often, and what evidence would satisfy a board that is not itself technical enough to read the underlying code. None of this is a reason to resist embedding compliance into products. It is a reason to treat the embedding itself as something that needs governing, not simply implementing.

What Firms Should Do Now

The first step is to bring governance and compliance into product and technology planning early enough to influence design. This does not mean putting another approval gate in front of every product decision. It means identifying the regulatory requirements that could materially affect the architecture, data flows, controls, monitoring or evidence the product needs before development is too far advanced.

The second is to distinguish between compliance that is claimed and compliance that can actually be evidenced. If a firm describes a product as compliant by design, secure by design or governed by design, the underlying architecture should be capable of supporting that statement. The question should not simply be whether the organisation has assurance that the product is compliant, but what evidence would exist if a client, auditor or regulator asked to see it.

The third is to keep regulatory timelines tied to the specific obligations that actually apply. For organisations developing or deploying AI systems in scope of the EU AI Act, this means understanding the classification of the system and the corresponding application date rather than treating 2 August 2026 as a universal deadline for every high-risk AI obligation. The Act's current implementation timetable differentiates between different categories of high-risk systems, with certain obligations applying later.

The fourth is to give embedded controls clear governance ownership once they exist. This means naming who is accountable for a control that lives inside a product, and building periodic independent assurance over it into existing audit or risk committee cycles, so that responsibility does not quietly disappear as the product evolves after launch.

The principle remains the same: where a requirement depends on the system being capable of producing particular evidence or operating in a particular way, organisations should address that requirement during design rather than wait for a compliance review to expose the gap.

Conclusion

The organisations best placed over the next several years will not be the ones with the most comprehensive compliance policies. They will be the ones whose products carry the evidence of compliance within them. Regulation, in this sense, is no longer only a constraint applied to innovation. Increasingly, it is becoming part of what innovation has to deliver.

This insight does not attempt to predict how every regulator will act next. It exists to help boards and leadership teams decide, today, how their products should be built, because they understand what is already being asked of them.

Prepared as part of CCC Advisory’s regulatory insights and advisory work.

© CCC Advisory. All rights reserved.