Finding the right regulation is rarely the hard part of regulatory work, and software can already do that well. The hard part is judging what that regulation, your own procedures, and everything you have told the regulator before allow you to conclude about a specific situation. When a company changes a product that is already cleared or approved, someone has to decide what that change means to each regulator. A new supplier, a new sterilization facility, a software update, a labeling edit: each one is assessed, market by market, before it goes ahead. That work is called change assessment, and it is where that judgment shows up most. Earlier in my career, in post-market regulatory affairs, it was most of my job. Today I work in regulatory intelligence, tracking changes in regulations and guidance, but change assessment is still close to my work. Each assessment ends in one of three outcomes, which we call the disposition:
-
No regulatory action beyond an internal record, usually called a letter to file for 510(k) devices. For PMA devices, a change with no effect on safety or effectiveness may still be reported in the periodic report.
-
A notification, which means telling the regulator about the change.
-
A new submission, which means getting clearance or approval from regulatory authorities again before the change can go ahead.
The answer depends on what the manufacturer says the product is for (its intended use), how it is classified in that market, what we told the regulator before, and commitments that still apply. For a company selling globally that can mean 30 to 50 markets, and no change is small enough to skip the process.
It looks like work an AI agent could learn from past cases. Guidance documents and decision trees say what each type of change requires. Past assessments show how the company handled similar changes before. I built a prototype AI agent to test whether that is true. I wanted to know whether it could land on the right disposition and explain why: why this change needs a notification and not a new submission, in terms that would hold up if a regulator or auditor asked me to defend it a year later. It matched my answers 75 to 80 percent of the time. What that number can’t show is whether those answers were right. This article sets out three gates a past decision should pass before an AI agent reuses it, and what a team building such a tool would need to put in place.
What I built
This was a personal experiment, not a system my company uses. It isn’t validated, nothing in it is proprietary, and I am not a software engineer. By agent, I mean an AI model set up to read documents, ask questions, and draft an answer. I built it on a general-purpose AI model and limited it to FDA and the US market. Other regions use different terms and thresholds, such as the EU’s concept of a significant change, so the dispositions here are US-specific.
Everything the agent works from is made up. I wrote about 25 mock change assessments, with invented products, invented company procedures and the disposition each case reached. I loaded them, along with public FDA guidance, into a knowledge base: a set of documents the agent can search. I did not retrain the model. I walked it through each mock assessment instead, showing it how to read the guidance, how to compare a new case against a past one, and why that change led to that outcome, and I corrected it when it went wrong.
I also built a template with the fields an assessment needs: what the change is, why it is being made, which products and markets are affected, whether quality procedures are touched, and what testing supports it. The agent uses the template to ask clarifying questions, the way a colleague reviewing the form would. Then it drafts a disposition, lists the guidance and past cases behind it, and I review it. I designed it as decision support, not an autonomous agent: it drafts a recommendation for a person to review and never makes or files a determination itself. I never ran it in a GxP environment, the regulated setting where records have to meet quality-system rules, because it was never meant to inform one.
To test it, I gave it a second batch of 25 mock assessments I wrote myself, which it hadn’t seen, and asked it to work them out on its own. Its disposition matched mine about 75 to 80 percent of the time. But getting there took a lot of correction. That is a prototype observation, not a validated result. It did well where the guidance is explicit, such as a change to intended use, a new statement in the instructions for use, a new device size, or a like-for-like supplier change. It struggled where the answer needed judgment beyond what was written down. It finished all 25 in about ten minutes, but speed doesn’t help if the answer is wrong.
Where it looked most useful was triage, as a first pass before a request reaches regulatory. Many change requests start outside regulatory. R&D proposes a new supplier, quality wants to change a sterilization process, labeling wants to update a statement, and none of them can easily tell which path the change will take. It might be a letter to file, a short notification, a supplement or a full new submission, and the gap between the first and the last can be months of work. A small-looking change can also land on a longer path than anyone expects. A tool like this could give the requester a rough early read, enough to decide whether the change is worth pursuing and to arrive with the right information. It does not replace regulatory expertise. The disposition, and the reasoning behind it, still come from a regulatory professional, who knows the classification, the commitments, and the history that no template captures. What the tool changes is where that expertise is spent: on the real determinations, not on every early question. For a small, stretched team that difference matters most, and I come back to it below.
The test also raised a harder question: what if the past decision the agent agreed with was itself the wrong call? In real work, the answer to “was that the right call?” arrives late. Suppose a company lists a change in its annual report to FDA, the yearly filing for a device approved through premarket approval, reasoning that it didn’t need approval first. Months later, the regulator disagrees and says it needed a different pathway before the change was made. By then the product has been on the market under the original decision for most of a year, and the record is corrected after the fact.
If that case had been in my mock examples as first decided, the AI agent would have relied on the original call as if it were right. It has no way to know the record was later overturned unless someone updates it. The gap between agreement and correctness only closes when the regulator speaks, and by then the agent has already used the earlier version. That gap is why a past decision has to clear three gates before an agent can use it.
Three gates between a decision and reusable context
Dan McCreary has argued that the unit worth modeling is the trace behind a decision: what happened, why, who approved it, which precedent supported it, what was true at the time, and the conversation that authorized it, even an informal one that was never written down.
In change assessment, we keep the disposition and some of the reasoning, usually in a rationale memo. We almost never keep the authorizing conversation, such as a senior reviewer saying “I’m comfortable with this because of X.” That is often the most useful part for anyone learning from the case later.
Capturing the trace still leaves a question: when is it safe to let a past decision guide the next one? In regulated work, a past decision has to pass three gates first, and each one needs a person for a different reason.
- Can this precedent apply here? Someone has to decide whether the new case is truly like the old one or only looks like it.
- Can the reasoning be inspected? We write rationale routinely, but a written rationale can be a tidy reconstruction instead of a record of what happened.
- Can the system use the new context? For regulated use, a system has to be validated, and adding new material to what it relies on is a change that needs review. This only applies to GxP use.
Three gates between a past decision and reusable context | Source: Author
Gate one: what can this precedent establish?
As noted earlier, change assessment looks like work an AI agent could learn from past cases. Gate one asks what those past cases are actually allowed to tell it. Ten similar assessments show what was decided ten times. They don’t authorize an eleventh. A past case may have been decided under a regulation or company procedure that has since changed, or under different leadership with a different view of risk. It may have turned on a fact that was easy to miss. Or it may reflect a cautious habit nobody has re-examined, the kind that becomes company culture without anyone choosing it. Sources also carry different weight:
Past assessments inform, but do not authorize | Source: Author
Three examples show how that works in practice.
- A like-for-like supplier change. Take a supplier change where the component is the same material, made to the same specifications, but bought from a different manufacturer. Suppose it’s a non-critical component on a 510(k)-cleared device. The company still runs its usual verification and testing, a documented risk assessment finds no new concerns, and the design and product specifications don’t change. In the cases I built, changes like this were consistently handled with an internal record, a letter to file. Here precedent speaks for itself: the pattern is clear and the risk hasn’t changed, so the agent can say “this is how we’ve handled it before.” The same change on a PMA device could mean a 30-day notice if the component is critical, or an annual report entry if not, which is why the agent must know the pathway before it applies a precedent.
- A change to an AI-enabled device. A change touching an AI-enabled device’s intended use or performance claims is different. The AI agent pulls guidance and similar cases, but a person writes and owns the argument, because it may have to be defended to a regulator/auditor later.
- A question the regulator has already settled. And where the regulator has already ruled on the same kind of change to our own product, precedent doesn’t count. Once someone has confirmed that the ruling still applies, it is an instruction that settles the question, and no pattern in other past cases can override it, however confident the model sounds.
One more distinction applies to all three gates: who is deciding.
Precedent is a record of what people decided before. It is not a source of authority. If an agent decided on its own, with no person reviewing the output, a similar past case would be doing the work that regulation, current guidance, and the facts of the new change should do. Any mistake in that past case, such as the overturned annual-report decision above, would be copied forward without anyone noticing, and a confident answer would make it harder to spot. A decision has to rest first on what is binding today, so precedent alone should never be enough. In my view, an agent shouldn’t make that determination on its own at all.
The picture changes when the agent prepares a recommendation for a person to review. Then precedent can be shown freely. Seeing that a similar case went a certain way tells the reviewer what has been done before. The reviewer, who knows the product and its history, decides whether the facts really match or something has changed. The restriction protects the moment of decision. It does not limit what the agent may gather and show beforehand.
Gate two: can the reasoning be made inspectable?
Gate one assumed a past case applies. Gate two asks whether I can see why it was decided the way it was, or only what was decided.
A quality record holds more than one thing. The first is the disposition, the outcome itself, such as a letter to file or a new submission. The second is the rationale, the written chain of reasoning from the facts of the case to that outcome. The third is the weighing that produced it: why someone leaned cautious, or which past near-miss made them look harder. A good rationale lets a later reader follow the logic. The weighing tells them whether that logic still holds for a new case, and it is the part that most often goes missing.
As regulatory affairs professionals, we do write rationale, and that is routine. The weak spot is timing. A rationale written after the decision tends to read as clean and confident, as if the answer was obvious from the start. It often leaves out what actually happened: the disagreement in the room, the detail someone was uneasy about, and the reason a senior reviewer gave in a conversation nobody wrote down. That moment is often the real reason the decision landed where it did. An AI agent that retrieves the memo inherits the same gap. A written rationale and an inspectable one are not the same thing. I return to this at the end.
Gate three: can the system use the new context?
This gate applies only to some uses. GxP is the set of quality rules for regulated work, and a system is in GxP use when its output feeds a regulated decision: one that touches product quality, patient safety, or records a regulator could ask to see. My prototype wasn’t, because nobody relied on its output. The same tool could be GxP in one use and not in another.
If it is GxP, the system has to be validated, meaning documented evidence shows it reliably does what it is meant to do. It also has to stay that way, and the tool for that is change control, a formal process that assesses any change before it goes live. That covers new content as much as new software and configuration changes.
This is the part that surprises people outside regulated work. Adding a past case or a revised guidance document to the agent’s knowledge base is a change to the system, the same kind of change as editing a formula in a validated spreadsheet. The file can be indexed in minutes. That doesn’t make the result validated or safe to rely on. Someone has to assess the impact first and, where warranted, test it.
The risk also runs the other way. If guidance changes and the knowledge base isn’t updated, the system works from stale context. Update carelessly and the system is unverified. Update too slowly and it is out of date. The gap between the moment the organization learns something and the moment its system is allowed to use it is what I think of as controlled context lag. It sits beside context drift, context changing without the evaluation process noticing. Lag runs the other way: everyone has noticed, and the system isn’t yet allowed to reflect it.
Drift: nobody noticed. Lag: everyone noticed, and the system can't use it yet | Source: Author
Medtech already has a model for shrinking that gap, though it was written for a different purpose. FDA’s Predetermined Change Control Plans (PCCPs) let a manufacturer agree in advance which changes a device may make and how each will be validated, so those changes can go ahead without a new submission each time. The mechanism applies to medical devices generally, not only AI-enabled ones. It does not cover AI used inside a company’s own processes, such as a tool that supports change assessment. For software used in production or the quality system, FDA’s framework is Computer Software Assurance, a risk-based approach to validating that software for its intended use. It does not offer a pre-agreed change plan of the same kind. The principle still carries over: agree up front what a system may change and how each change will be checked, and the change can move quickly when it arrives. As far as I know, no equivalent exists yet for AI-enabled GxP processes in manufacturing or the quality system.
What a team building this would need
The three gates translate into a short list of requirements for anyone building a tool like this:
- Tag every source with its authority level: law, guidance, SOP, our own correspondence with the regulator, or past assessment.
- Record when a past decision was superseded or overturned, with the date it took effect.
- Capture the reviewer’s reasoning when the decision is made, not afterward.
- Keep “retrieve and show” separate from “decide,” so precedent can inform a person but never decide alone.
- Put the knowledge base under change control, with versioned releases.
The third is the one I have not solved, and I come back to it below.
Is the juice worth the squeeze?
Everything above has a cost. A system like this has to be tested and maintained, and if it ever touches a regulated process, validated for a defined use. Whether an AI agent can help with change assessment is the easier question. The harder one is whether the work it takes off my plate is worth the system I’d have to build and run around it.
In my experience, that depends on workload and support. A small, stretched regulatory team has more to gain from triage than a large one. But most regulatory teams aren’t IT organizations, and maintaining and validating a tool like this in-house is where the idea can fall apart quickly.
The clearest gain I see is something I did not build mine to do. Our process today is manual, and the regulatory intelligence feeds return everything that changed everywhere. I work in women’s health and still receive cardiac updates. Fifteen items arrive, five apply, and finding those five is a job before the real assessment even starts. An AI agent could save time there, at low risk, because nothing is being determined.
What I would never hand it is the determination itself, made without a person reviewing it before anyone acts on it. The three gates are the reason. A precedent may be outdated, overturned, or already settled by a regulator’s instruction. A rationale may be a tidy reconstruction rather than a record. And the system’s context may be stale, or changed without review. Each of those needs a person.
Have I decided whether the value justifies the cost? Not fully. Right now, an AI agent is an intern, not a licensed professional. It’s welcome support, but not who you’d leave alone with a newborn, or with a determination that carries real regulatory and patient consequences. That may change as trust builds. It hasn’t yet.
The part I still can’t solve is the review conversation. A senior reviewer’s pushback can make a determination better and still leave the system no better equipped for the next one. The reasoning is spoken, settled, and then reduced to a memo that records only where we landed. I don’t know yet where it should live: a line in the memo, the review record, or something the AI agent reads directly. Right now it lives in the reviewer’s head, and it leaves with them. Until the reasoning behind an override is captured somewhere the next assessment can find it, review will keep improving decisions that the agent can’t learn from.
Geethapriya Setty writes in a personal capacity. The agent described is a personal prototype built on mock data and does not represent any system deployed by her employer.
The Cats of Context & Chaos
We regraded that one. | Source: Context and Chaos
About Context & Chaos
Context & Chaos isn’t just a newsletter. It’s shared community space where practitioners, builders, and thinkers come together to share stories, lessons, and ideas about what truly matters in the world of data and AI: context engineering, governance, architecture, discovery, and the human side of doing meaningful work.
Our goal is simple, to create a space that cuts through the noise and celebrates the people behind the amazing things that are happening in the data & AI domain.
Whether you’re solving messy problems, experimenting with AI, or figuring out how to make data more human, Context & Chaos is your place to learn, reflect, and connect.
Got something on your mind? We’d love to hear from you.
Share this article