Mapping Record Ownership Before AI Connects Your Quality Data

MedCity News recently published a piece on how AI is connecting medtech data without compromising compliance. Its argument is that the connected, agent-ready enterprise is the model that wins, where compliance and intelligence operate together. I agree with that direction, and I think the harder question for a mid-size device manufacturer sits one level down. Once an AI agent can read across your complaint system, your service records and your CAPA files, somebody has to decide which system holds the official record for each piece of information the agent touches, and where the agent's own output gets filed.

That decision belongs to quality and operations leaders more than to the IT team, because the answer determines what an FDA investigator or a notified body auditor will be shown. It is also much cheaper to settle before the integrations are built than after. And it shapes how much change control work the project will trigger in each validated system.

Why connected data raises the record question

Quality data in a typical device company lives in several places. Complaints may be logged in an eQMS or a CRM, field service findings in a service management tool, nonconformances in the ERP or MES, and design history in a PLM system. Each of those systems usually has its own validation status, its own access controls and its own audit trail. The company has also already decided which one is authoritative for its kind of data.

An agent that reads across those systems creates something new, such as a drafted complaint investigation, a trend summary or a suggested link between a complaint and an open CAPA. If that output is used to meet a requirement in the quality system, it is a quality record. Under 21 CFR Part 11, electronic records used for regulated purposes need audit trails and controls over who can create and change them. FDA's Quality Management System Regulation, which took effect in February 2026 and incorporates ISO 13485:2016, still requires that records be controlled and remain retrievable. None of that goes away because the record was assembled by software that pulled from five sources.

The risk here is quiet. If the agent copies complaint details into its own workspace, you now have two versions of the same complaint. When an investigator later edits the original in the eQMS, the agent's summary may be out of date, and nobody may notice until an auditor compares the two.

Build a record ownership map before you connect anything

The most useful document for this kind of project is a simple map of every data element the agent will use. For each element, it should name the system of record, the business owner, and whether the agent may read it, propose a change to it or write to it directly. It should also say where the agent's output will be stored and which system's audit trail will show what the agent did.

In a regulated setting, I think the default should be that the agent reads from the authoritative system each time and writes back only through that system's normal workflow, with a person approving the change. That keeps one version of each record, and it keeps the approval inside an audit trail your quality team already understands. Drafts the agent produces should be stored with a reference to the source records and the specific versions it read. A reviewer, or an auditor two years later, can then see exactly what the agent was looking at.

Laminar's work for Axonics, a medical device company later acquired by Boston Scientific, followed the same principle in a different context. We replaced an iPad-native quoting app used by more than 300 sales staff with an Azure web application that pulls pricing from the ERP. That project had no AI component. The design point still carries over, because the application reads pricing from the system that owns it, and the ERP remains the source for pricing.

Where the friction will come from

Expect resistance from a few directions, and plan for it early. Adding an interface to a validated system is usually a change that goes through change control, and each source system may have a different validation owner and a different release schedule. Some legacy systems have no clean way to expose data, which pushes teams toward nightly extracts and spreadsheets. Those copies are exactly what the ownership map is meant to prevent. If the agent runs on a vendor's cloud platform, that vendor also needs to be evaluated under your supplier controls.

Quality staff will also be skeptical of drafts they did not write, and they should be. A complaint investigator who signs an investigation is accountable for it. The workflow has to show reviewers the source records alongside the draft and make it easy to reject or rewrite what the agent produced. If reviewers end up approving drafts without checking sources because checking takes too long, the connected system has weakened the records it was meant to support.

Practical next steps