AI in Pharma
MBR Design:
Fears and Future
Why the speed of AI authoring is creating a quieter, more expensive problem.
Max Ryan
Senior MES Manager
Published 21st July 2026
ON THIS PAGE
Why the speed of AI authoring is creating a quieter, more expensive problem
Last quarter I watched an AI tool generate 184 batch record steps from a stack of paper MBRs and SOPs in under an hour. It would have taken our team three weeks, but about 30 of those steps shouldn’t have existed.
The AI had faithfully translated everything in the source documents, including a manual reconciliation that hadn’t served a real purpose since 2014, a sign-off step left over from a quality event in 2018, and three “verify and document” checks that duplicated what the equipment was already recording electronically.
This is the paradox sitting at the centre of every AI-assisted MBR project in 2026 as the tools are now fast enough to compress an 8-to-12-month development cycle into 4-to-6, but they’re also fast enough to enshrine a decade of accumulated process cruft into your new electronic batch record before anyone has time to ask whether those steps should still exist.
What AI is actually good at
The current generation of AI tools, large language models fine-tuned on pharmaceutical documentation, paired with retrieval against your site’s existing procedures, is genuinely transformative for the first 70% of MBR development. Reading paper SOPs and extracting procedural steps. Mapping those steps to standard recipe phases and unit operations. Generating draft prompts, data fields, and instruction text that follow your site’s authoring conventions. Identifying inconsistencies between SOPs and existing batch records. Creating common design steps based on those batch records.
These are the tasks that historically consumed the bulk of an MBR project’s authoring budget, and they’re exactly the tasks where AI has a structural advantage. Pattern matching across thousands of pages of documents is something machines do better than people, every time.
The 8-to-12-month MBR development timeline collapsing to 4-to-6 months isn’t marketing copy; it’s what we’re seeing on projects where AI is integrated thoughtfully into the authoring workflow. The “grunt work” of initial batch record creation like extracting, structuring, and templating, is going away.
What AI is structurally bad at
AI is faithful to its source material and while that can seem like a flaw, really it’s the defining characteristic. A model reading a paper batch record will reproduce what’s in that batch record and won’t ask whether the manual reconciliation step at line 47 still serves a purpose. It won’t question why the operator has to sign three different times during a CIP cycle. It won’t notice that the “verify and document” check on equipment data has been completely redundant since you installed the new historian in 2021.
The AI doesn't know what good looks like. It only knows what your site looks like."
This is the “AI slop” risk in MBR development, and it’s worse than the AI slop you see in general content, because it is a regulatory exposure surface. Every non-value-added step is a step where operators can deviate from procedure and every redundant check is a verification that has to be reviewed, signed, and held for the document retention period. Every legacy sign-off carries its own deviation potential.
Slop can be seen as noise instead of exposure
Modelled at scale, AI-assisted MBR development without process challenge produces records that are faster to build, faster to execute, and faster to inherit yesterday’s workarounds.
The deeper problem: AI removes the only forcing function we had
Today, a successful MBR project at Pangaea starts with a process rationalisation phase, typically four to eight weeks before a single batch record is built, where the manufacturing team, process engineers, and quality leads sit down and ask the questions the AI never will. Questions like which steps are still earning their place? Which sign-offs exist because of a regulation, and which exist because of a quality event in 2018 that nobody remembers and was potentially resolved through new equipment or monitoring? Which manual checks are duplicating what your equipment historian already captures? Done properly, this phase produces a shared understanding of what the batch record is really trying to achieve. The AI then builds on that and what you get at the end is a faster project and a better record, not a choice between the two.
For two decades, the act of manually converting paper batch records into an MES has been the single best opportunity most pharma sites get to lean out their processes. The work was hard enough that someone, somewhere in the project, would inevitably ask: why are we doing this step?
The friction of the conversion process forced the conversation but now AI removes that friction and when you remove the friction, you remove the conversation.
This is why an AI-assisted MBR project, done badly, is worse than a paper-to-electronic conversion project done well. The paper-to-electronic project might take 12 months and produce a leaner batch record. The AI-assisted project takes 4 months and produces a digitised version of every accumulated workaround your site has invented since the building opened.
You went faster. You did not go better."
What to do about it
There are measurable productivity gains, the technology is improving, and sites that don’t adopt these tools are going to find themselves outpaced by competitors who do. But it does change what an AI-assisted MBR project needs to look like.
Three principles:
First, separate generation from validation. Use AI for the first-pass draft, the 70% build of paper documents, and then explicitly schedule process challenge sessions before any AI output becomes a controlled MBR. The time you save in authoring becomes time you spend questioning what you’re authoring. That’s not overhead.
Second, instrument the AI’s blind spots. Build review checks specifically targeted at the categories AI will get wrong: redundant data captures, legacy sign-offs, manual reconciliations against automated systems, and “verify and document” steps that duplicate equipment data. Your AI tool can be taught to flag these for human review even when it can’t decide them.
Third, treat the MES implementation as the lean-out, not the digitisation. The technology choice, paper to electronic, on-prem to cloud, conventional to AI-assisted, should never be the strategic objective of an MBR project. The strategic objective is a leaner, more compliant, more executable process. The technology is what carries that process forward.
The faithful machine
The AI is faithful. The question is: faithful to what?"
AI will continue to change how MBRs are developed, and the productivity gains are too significant to ignore, but AI is only as valuable as the process it is translating. If yesterday’s workarounds, redundant checks, and unnecessary sign-offs become today’s electronic batch record, then the technology has simply preserved the past more efficiently. The real opportunity is to use AI to accelerate the work of building better batch records, and not just faster ones.
About Pangaea Life Science Solutions
Pangaea Life Science Solutions is a Cork-based technology and consulting firm helping pharma and biotech manufacturers design, deploy, and optimise Manufacturing Execution Systems. We work with CIOs and operations leaders to convert paper batch records, modernise legacy MES platforms, and integrate AI into authoring and execution workflows without inheriting the process debt of the past.