From Regulatory Requirements to Trusted Data: Building the Foundation for Digital Quality and AI 

In regulated life sciences, we spend a great deal of time interpreting requirements. We determine what information regulators expect, what must appear on a label, what belongs in a submission, what needs to be reported to a regulatory database, what evidence must be maintained, and what controls are necessary to demonstrate compliance. Yet somewhere between interpreting a regulatory requirement and implementing it across an organization, something important happens: the requirement becomes data.

​

A requirement that begins as language in a regulation, guidance document, or technical specification eventually has to become something operational. It may become a product attribute, a data definition, a business rule, a controlled value, a system field, a workflow requirement, or a reporting obligation. That information may then move across functions and systems, change throughout the product lifecycle, support multiple downstream processes, and ultimately become part of what the organization communicates to a regulatory authority.

​

For much of my career in global Regulatory Affairs and regulatory data governance, I have worked in this space between the regulatory requirement and the enterprise data needed to operationalize it. That experience has shaped how I think about data governance. I do not see regulatory data governance simply as a data management discipline. I see it as part of the mechanism through which an organization translates regulatory intent into sustainable business capability.

​

That distinction is becoming increasingly important as Quality and Regulatory organizations modernize their digital environments and begin integrating artificial intelligence into regulated work. We frequently say that digital transformation and AI require trusted data. I agree. But if trusted data is the foundation, we need to understand how that trust is actually created. In regulated environments, it begins much earlier than the database.

 

A Regulatory Requirement Does Not Arrive as a Data Model

​

Regulators generally define what information they expect and the conditions under which it must be provided. They do not design the enterprise operating model required to produce and maintain that information. The organization still has to translate the regulatory requirement into something that can be consistently understood and executed.

​

Consider a product attribute required for regulatory reporting. The requirement may tell us what must be reported, but the organization still has to determine precisely what that information means for its products. Which products does the requirement apply to? What is the authoritative source? Who creates the information, and who owns it? At what point in the product lifecycle should it be established? What happens when it changes? Which systems consume it? What business rules apply? What evidence supports the value? How should exceptions be handled?

​

These questions quickly extend beyond Regulatory Affairs. Engineering may create the underlying product information. Quality may govern related controls. Manufacturing or Supply Chain may maintain information required downstream. Labeling, Master Data, IT, and Commercial functions may consume or transform it. Different systems may even use different terminology or structures for concepts that ultimately need to represent the same regulated product.

​

At that point, what began as a regulatory requirement has become an enterprise data and process question. If that translation is not intentionally designed, organizations can end up in a familiar situation: the regulatory requirement is understood, but the data needed to satisfy it is fragmented across functions, systems, spreadsheets, documents, and institutional knowledge. Compliance can still be achieved, but it depends disproportionately on human effort, reconciliation, and the knowledge of experienced individuals rather than on a sustainable organizational capability.

​

Regulatory Data Often Begins Somewhere Other Than Regulatory

​

One of the most important lessons I learned working with global UDI and regulatory product data is that Regulatory Affairs is frequently not the original creator of the information it ultimately becomes responsible for reporting. By the time Regulatory needs a particular attribute, that information may already have moved through several processes and systems.

​

This creates an important upstream dependency. If a definition was unclear when the information was first created, if ownership was never established, if the data was captured at the wrong level of granularity, or if a product change did not trigger the appropriate downstream activity, the problem may eventually appear as a Regulatory data issue. But the root cause can exist much earlier in the product lifecycle.

​

That is why regulatory data governance cannot begin at the point of submission or reporting. It needs to reach upstream into the processes where regulated information originates and establish the relationships between regulatory requirements, data definitions, business rules, ownership, lifecycle events, and systems.

​

When I led global UDI master data governance work at Baxter, one of the most important capabilities we developed was a regulatory data dictionary encompassing more than 250 regulatory data requirements. The value was not simply in documenting a large number of attributes. The more important work was translating regulatory requirements into a common enterprise language that could connect regulatory interpretation with product information, business processes, system requirements, governance, and lifecycle management.

​

That experience reinforced a principle I continue to carry into transformation work: a regulatory requirement becomes sustainable when the organization can translate it into a governed business capability. Without that capability, every new requirement risks becoming another data collection and reconciliation exercise.

​

A Data Dictionary Is Really an Agreement About Meaning

​

The term data dictionary can make this work sound technical or administrative. In practice, a well-designed regulatory data dictionary is much more than a catalog of fields. It is an agreement about meaning.

​

A useful regulatory data definition helps different parts of the organization interpret the same information consistently. It establishes what the attribute represents, which requirement drives it, when it applies, what values are permitted, who is accountable for it, where the authoritative information originates, and how it relates to other product information. Those decisions provide the semantic foundation that allows processes and technologies to work together.

​

This matters because organizations can achieve technical integration without achieving shared meaning. Two systems may exchange information perfectly while the functions using those systems interpret the information differently. An integration can move a value from one application to another, but it cannot determine whether both sides understand that value in the same way.

​

This distinction becomes increasingly important as digital environments become more connected. Integration moves information; governance preserves its meaning. If we want information to remain trustworthy as it travels across functions, processes, systems, and markets, both capabilities are necessary.

 

Trusted Data Has to Be Designed Into the Process

​

Data quality is often addressed after information has already been created. Organizations run completeness reports, identify invalid values, reconcile systems, correct records, and create dashboards to monitor quality. Those activities are necessary, but they address the problem relatively late in the lifecycle.

​

A more sustainable approach is to design for data quality at the point where the information originates. That requires clear definitions, appropriate ownership, authoritative sources, lifecycle rules, business controls, and accountability. It also requires processes that create and maintain the information at the appropriate point in the product lifecycle and systems that preserve its meaning as it moves downstream.

​

This is where process transformation and data governance become inseparable. A poorly designed process can create poor data even when the technology performs exactly as configured. If ownership of an attribute is unclear, the system cannot decide which function should be accountable for it. If two functions use different definitions, integration alone cannot determine which interpretation is correct. If a product change should trigger a regulatory data update but that relationship has never been defined, automation cannot reliably compensate for the missing business rule.

​

These are not primarily technology problems. They are organizational design decisions that technology can enable and enforce once the organization has made them.

​

Data Ownership Is Not the Same as Data Entry

​

This becomes particularly visible when organizations discuss data ownership. It is easy to assign responsibility for entering information into a system and conclude that ownership has been established. But the person who enters a value is not necessarily the person or function accountable for its meaning, quality, lifecycle, and appropriate use.

​

In a global product environment, those responsibilities may cross functional boundaries. Regulatory may define why information is required and how it will be used for compliance, while Engineering may remain authoritative for the underlying technical characteristic. Another function may maintain the value in the enterprise system. If the information changes, the process must ensure that the regulatory implications of that change are recognized and acted upon.

The governance model therefore has to connect data ownership, process ownership, regulatory accountability, and system responsibility rather than assuming they are the same thing. When those relationships are explicit, data quality becomes less dependent on individual knowledge and more embedded in the operating model. That is an important shift from reactive compliance toward sustainable compliance.

​

Global Requirements Make Enterprise Thinking Essential

​

Global regulatory environments make this challenge even more complex because requirements are neither static nor identical across jurisdictions. The same product may need to be represented differently depending on market, classification, packaging configuration, lifecycle status, or reporting obligation. New requirements continue to emerge while existing ones evolve.

​

One way to manage this complexity is to treat each new regulatory requirement as an individual compliance project. A regulation changes, a team identifies the required information, the data is collected, a submission or database update is completed, and the organization moves to the next requirement. This approach can achieve compliance, but repeated over time it can also produce duplicate definitions, parallel collection processes, overlapping attributes, and multiple sources for essentially the same product information.

​

A more sustainable approach asks a broader question: What regulatory data capability does the enterprise need in order to support these requirements collectively?

​

That question changes the design. Instead of repeatedly collecting information for individual regulatory obligations, the organization begins developing a governed regulatory information model that can support multiple markets and use cases. Common product information can be defined once and reused appropriately, while genuinely market-specific requirements remain distinguishable. Ownership becomes clearer, lifecycle changes can be managed systematically, and new requirements can be evaluated against an existing information architecture rather than starting from scratch each time.

The organization begins moving from repeatedly responding to regulatory data requirements toward managing regulatory data as an enterprise asset.

 

The Same Principle Extends to Digital Quality

​

Although much of my direct experience with enterprise data governance has been rooted in Regulatory Affairs, the same principles extend across Digital Quality. Quality processes increasingly depend on connected information. Complaints, CAPAs, nonconformances, change controls, supplier information, training records, risk information, product data, and regulatory commitments intersect in ways that become more visible as organizations digitize their Quality environments.

​

The opportunity is not simply to replace paper, spreadsheets, or disconnected workflows with electronic systems. It is to create an environment in which information can be understood, traced, governed, and used across processes with greater confidence. That requires shared definitions, appropriate relationships between data, clear ownership, and processes designed around the lifecycle of the information.

​

Without those foundations, an organization can end up with a collection of modern digital systems without creating a genuinely digital operating model. The distinction is important: digitization changes the medium; digital transformation changes the capability.

​

AI Raises the Standard for Data Trust

​

Artificial intelligence makes the quality of this foundation even more consequential. Traditional regulated processes often allow experienced professionals to compensate for weaknesses in data structure and governance. A Regulatory professional may recognize that an attribute is incorrect because they understand the product and the requirement. A Quality professional may know that two records describe essentially the same issue despite inconsistent terminology. Someone who has worked in the organization for years may know which of several sources is actually reliable.

​

That institutional context does not automatically transfer to AI. An AI-enabled capability operates on the information and rules available to it. If definitions are inconsistent, sources conflict, ownership is unclear, or lifecycle controls are weak, those conditions become part of the environment in which AI is expected to operate.

​

This is why I believe AI readiness needs to include a much more nuanced conversation about data than simply asking whether enough data exists. Before using AI to analyze regulatory information, organizations should understand whether that information is sufficiently defined, structured, governed, and trustworthy for the intended use. Before asking AI to identify patterns across Quality data, they should understand whether classifications and definitions have been applied consistently enough for those patterns to be meaningful. Before allowing AI to support decisions, they should understand the lineage, limitations, and reliability of the information informing those decisions.

​

The standard is not perfect data. No mature enterprise has perfect data. The more useful question is whether the organization understands its information well enough to know where it can be trusted, for what purpose, under what controls, and with what level of human oversight.

​

Data Governance Should Reduce Ambiguity, Not Add Bureaucracy

​

Data governance is sometimes associated with committees, policies, approvals, and additional layers of control. When governance is designed that way, it can easily become another source of organizational complexity. Effective governance should instead make the organization easier to navigate by reducing ambiguity.

​

People should know who owns critical information, who has authority to change it, which definitions apply, where authoritative sources reside, how exceptions are handled, and how decisions are made when requirements conflict. They should not need to rely primarily on personal relationships or institutional memory to determine what is correct.

​

This is particularly important in regulated environments because the operating model must remain sustainable as people and organizations change. Experienced employees leave. Responsibilities move. Businesses are acquired. Systems are replaced. Regulations evolve. If compliance depends primarily on individuals remembering how the pieces fit together, the organization may continue to meet its obligations, but the capability remains fragile.

Good governance converts knowledge held by individuals into capability held by the organization.

​

From Regulatory Interpretation to Organizational Capability

​

When I look at the journey from a regulatory requirement to trusted data, I see a connected chain of organizational decisions. The organization must first understand the regulatory intent and translate it into clearly defined information. That information needs ownership and business rules. Processes must create and maintain it at the appropriate points in the lifecycle. Technology must enable those processes and preserve the meaning of the data as it moves. Governance must make accountability and controls visible, while people need to understand the responsibilities they carry within that system. Finally, the organization needs to know whether the entire capability is producing reliable outcomes.

​

Weaknesses anywhere in that chain tend to surface somewhere else. A definition problem becomes a data quality problem. The data quality problem creates reconciliation. Reconciliation creates manual work. Manual work leads to additional controls. Those controls become embedded in the operating model, and eventually a transformation initiative attempts to automate the environment that has accumulated around them.

​

This is one of the ways Transformation Readiness Debt™ develops, and it is also why regulatory data governance cannot be separated from the broader transformation conversation. Data is not simply an input to transformation. The way an organization defines, creates, owns, maintains, and trusts its data is itself part of the organizational capability being transformed.

​

Trusted Data Is a Business Capability

​

As regulated life sciences organizations become more digital, connected, and AI-enabled, Quality and Regulatory data will become increasingly valuable. But that value will not come simply from having more information or moving it more quickly between systems. It will come from knowing what the information means, where it originated, who is accountable for it, how it changes, where it can appropriately be used, and whether it is trustworthy enough for the decision being made.

​

Building that capability requires regulatory interpretation, process design, data governance, clear accountability, appropriate controls, capable people, and technology designed to support all of them. It reflects the same connected transformation perspective I have discussed throughout this series:

 

Strategy → Process → Data → Governance → Digital + AI → People → Outcomes.

​

For organizations preparing for the next generation of Digital Quality, Regulatory transformation, and AI, trusted data is therefore not simply a prerequisite we need to satisfy before adopting more advanced technology. It is an organizational capability that has to be intentionally designed and continuously sustained.

​

In regulated environments, that capability begins with something we already know how to do well: understanding the requirement. The opportunity now is to bring the same discipline to everything that happens between understanding that requirement and trusting the data that ultimately represents it.