Hey friends,

Last week we talked about 6 different kinds of context floating around in the conversation you have with an AI assistant. When most of us only think about 2 of them (usually the documents we uploaded and our prompts), it gets tricky to understand why a task went sideways. At best, exasperation and the temptation to start arguing with a chatbot. At worst, someone having a "Jesus take the wheel" moment and passing on an AI output that we aren't qualified to verify, but darn it, it sounds great because a computer wrote it.

But there's another layer to this. We say, well, if there are all these kinds of context being used in the conversation, and many of them are meant to make the model perform more to our liking, then more must be better! So we upload everything. We paste all the links. We add to our assistant instructions until it reads as long as the 5-book romantasy series we're currently hooked on.

Beware of "context creep." Stuff that you realize, yeah, that's true (I do like to find which seasonal vegetables are best for carving into the likeness of celebrities), but I don't need that included in my daily news brief for FDA regulatory updates.

Unfortunately, it's not always that obvious that the context of an AI interaction has been slowly contaminated with stuff you definitely didn't want. Here are some of the ways it happens:

Uploading all the documents you think might even be slightly relevant, when only the most relevant would do. Twelve documents doesn't make the answer more accurate, it just gives the model more to weigh and more chances to pull from the one that was superseded two revisions ago.

A draft becoming a source. The moment you ask for a revision, the thing being revised is the authority. Draft four is anchored to draft three, which was anchored to draft two, and somewhere back there is the guidance PDF nobody has looked at since message one.

Interpretations becoming assertions. "This may be read as requiring X" in the first version turns into "this requires X" by the fourth. Nobody added a claim, the hedge just stopped surviving each rewrite.

A side question becoming part of the main task. You stop to look something up in the same chat, get your answer, and move on, except the model didn't move on. That detour is still in the conversation, still carrying weight, still shaping the tone and the assumptions of everything after it.

Scope drift. You opened the chat to investigate a deviation and you're now three tasks downstream drafting the CAPA in the same window, with every assumption from the first task still along for the ride.

When doing regulated work, provenance is critical, AI-assisted or not. Claims have to trace back to something, and it all gets very muddy when we don't know what's going on inside the chat. This is why I like an "evidence-first drafting" strategy for tasks like this. Before you start on the real output, have the model tell you what it's working from, what it thinks the task is, and which document it would go to for what. It takes about ninety seconds and it sets expectations on both sides.

Here's what else we can do to keep context creep from getting away from us:

One task, one chat. New chats are free. Arguing with a stale one costs you time and sanity.

Length isn't the trigger, a change in task is. A long conversation that stayed on one deliverable is usually fine. A short one that wandered into three different jobs is the problem.

Ask what it's using. "What are you basing that on?" is a perfectly good question to ask mid-task. If it points to your source document, great. If it points to something it wrote forty messages ago, you may have found your creep.

Break the loop on purpose. When a draft is close, take it out, verify it against the actual source, and bring it back in as a clean attachment with the reference alongside it. You're resetting the evidence base instead of stacking another revision on top of the pile.

Prune your standing instructions once in a while. The thing you added in March to fix a formatting annoyance is still running today, on every task, whether it fits or not.

Like most things when working with generative AI, this is a competency and less of a cool tech trick. It might be a new way of thinking, but it's something all workers using AI should start to take seriously.

Thanks for reading!
-Alexa 

News

Kymanox launches AI-enabled quality and regulatory services

What's New: Kymanox, a global life science consulting firm, announced on August 6 that it is applying AI to three of its service lines: QMS development, batch release report review, and human factors data analysis. The work runs on a proprietary "KAI Engine" the company describes as purpose-built for regulated work, with qualified Kymanox subject matter experts verifying every output before it reaches a client. Worth noting what this is and isn't: it's a consultancy adding AI to its own delivery, not a software product you buy and run yourself. The people already writing your SOPs are now writing them with AI, and telling you so.

How It Works:

• The stated design principle is to apply the right AI capability to each task rather than pointing one general-purpose model at everything. The published workflow is four steps: your source documents go in, the engine does the volume work, a qualified SME approves the output with an auditable trail, and the deliverable comes out.

• QMS work covers SOP and work instruction authoring, form and template standardization, gap assessments, documentation harmonization, and bulk migration during remediation or M&A.

• Batch release review covers paper batch records, flagging discrepancies in release documentation, GDP and ALCOA+ data integrity review, and surfacing deviations for expert disposition.

• The human factors piece runs on a platform from Sanai, an AI company focused on pharma and biotech, customized and deployed for Kymanox. It automates aggregation, review, and summarization of study data into regulatory-ready reporting for combination products and devices.

• On data handling: enterprise-grade encryption, role-based access, full segregation between clients, and client data is never used to train models. On governance: a defined structure with risk assessment, mitigation protocols, and escalation pathways, plus stated alignment with FDA AI guidance and the EU AI Act.

• Available now, but only to clients who approve the use of AI as part of the engagement, with expansion planned through late 2026 and into 2027. How AI was used is specified in each SOW.

Why It Matters: For a lot of small and mid-size companies, the QMS documentation, the gap assessment, and the human factors report were never written in-house to begin with. They were written by a consultant. So this is AI arriving in your quality system through the vendor layer, which is a door most supplier qualification programs aren't watching. Go read your quality agreement with your consulting partners and see whether it says anything at all about AI-assisted deliverables, because I'd guess it doesn't. The batch release piece is the one I'd look hardest at, since documentation review supporting disposition sits about as close to the GxP line as an "assistive" tool can get. Kymanox's own framing is that AI accelerates the work and experts own the outcome, which is the right principle. The open question for any client is what verification actually looked like on their specific deliverable.

Source: GlobeNewswire — Kymanox Launches AI-Enabled Quality and Regulatory Capabilities (August 6, 2026) | Kymanox — Artificial Intelligence Solutions | Startup Fortune (August 11, 2026)

Does CSA cover AI? FDA's February guidance says the framework applies

What's New: Westbourne, a validation and IT services firm, published a piece on August 5 arguing that yes, Computer Software Assurance covers AI, because FDA's final CSA guidance explicitly names AI/ML tools alongside automation tools, data analytics, and cloud computing. Checking that against the guidance itself, the claim holds up with a nuance. It says the approach outlined can be applied, though is not limited to automation tools like bots and automatic workflows, data analytic tools, AI/ML tools, and cloud computing when used as part of production or the quality management system. So the guidance is telling you CSA is an appropriate method for these tools, and the actual validation obligation comes from elsewhere. Westbourne makes the same point in the piece: this is a scope clarification, not permission to turn AI loose in a GxP environment.

How It Works:

• Two dates matter. The current version was issued February 3, 2026 and supersedes the September 24, 2025 final guidance, with the revisions made under Level 2 procedures largely to align with the amendments to 21 CFR 820. That's a real caveat on the "it's new" framing, because the AI/ML sentence may well date to the September version rather than February. It's certainly newer than the 2022 draft.

• This is a device guidance from CDRH and CBER, prepared in consultation with CDER, the Office of Combination Products, and the Office of Inspections and Investigations. The validation requirements it points to now come from ISO 13485:2016, which the QMSR incorporated by reference into Part 820 effective February 2, 2026. Drug manufacturers under Part 211 are not the audience, though plenty of them borrow the thinking anyway.

• The framework runs in five steps: identify the intended use of each feature, function, or operation, determine whether it's used as part of production or the QMS, decide whether failure poses a high process risk, select assurance activities proportionate to that risk, and establish a record. Software for general business processes not specific to production or the QMS, like email or accounting, generally falls outside it entirely.

• Among the things FDA lists as generally high process risk: software that measures, inspects, analyzes, or determines acceptability of product or process "with limited or no additional human awareness or review." Read that clause twice, because it's doing a lot of work.

• Westbourne's argument for why AI validation stays hard anyway rests on three properties: non-determinism, since CSA testing assumes consistent behavior; explainability, since documented rationale is hard to produce when the tool can't show its reasoning; and model drift, since tools that change autonomously after go-live alter their own risk profile at a moment nobody scheduled. Their view is that continuously learning models are the biggest open question, with no clear guidance or best practice yet, and that a model frozen on a fixed dataset sits much closer to traditional software.

Why It Matters: The most useful thing in the guidance isn't the AI sentence, it's a pair of ERP examples that show what human review is worth in regulatory terms. In the first, software automates material ordering and delivery, but a qualified person checks the materials before use, so a mix-up gets caught and the manufacturer calls it intermediate, not high, process risk. In the second, the same software also automates the checking and no qualified person looks first, so it becomes high process risk and the assurance effort scales up to match the device risk. Same software, same failure mode, different answer, and the only variable is whether a competent human is standing between the output and the product. That's the risk-tiering logic I keep writing about, except it's FDA's and it's in a final guidance. The guidance is also explicit that existing process controls and downstream verification can be leveraged to reduce assurance effort. Your review step isn't overhead sitting on top of validation. It is part of the validation argument.

My Take: Two things I'd watch. The first is where the line is drawn for general-purpose assistants. A tool for general business processes isn't in scope, but software that maintains a quality record is used directly as part of the QMS. So what about a chat assistant that drafts the SOP? Nobody's answered that cleanly, and I don't think the real answer is "obviously out of scope" once the drafting is routine and the reviewer is rubber-stamping. The second is that CSA sets the evidentiary bar without telling you whether a given AI tool can clear it, which is Westbourne's real point. If you're being sold an AI-enabled QMS module right now, the vendor question isn't "is it CSA-compliant," it's "what's your change control when the underlying model updates, and how will I know it happened?" And if you can't get a straight answer, freeze the version or keep a human on the acceptability decision, because that's the move the guidance itself rewards.

Source: Westbourne — Does CSA Cover AI? What the FDA's Guidance Means for AI/ML Tools in GxP Environments (August 5, 2026) | FDA — Computer Software Assurance for Production and Quality Management System Software (February 2026 final, full PDF)