A New Standard for AI in Regulated Industries

The Model Context Protocol (MCP) is emerging as the standard way for AI assistants to work with other systems. In most industries that is a convenience — an assistant that can look something up or manage a calendar. In life sciences it is more consequential: a structured way to let AI take part in GxP work while keeping the controls regulators expect.

At DnXT we have been building on this standard since March 2026 — not as a product announcement, but as internal tooling our own team uses every day. We are now designing the next step: opening that capability to our customers’ AI assistants.

What We Have Built So Far

Our internal tooling covers three areas:

  • Looking at regulatory information. Nine tools for asking questions of the platform’s information. Read-only is enforced by the tools themselves, not by policy — there is simply no way to change or remove anything through them, and the amount that can be returned at once is capped.
  • Managing the platform. Thirteen tools for deployment, checking logs and verifying settings. Anything affecting production requires explicit double confirmation before it runs.
  • Checking code quality. Eight tools that run checks before any release, catching the specific mistakes that have caused problems for us before.

These are tools for our own engineers. They assume a trusted operator, and they have no customer sign-in, no separation between customers, and no usage limits. Useful internally — not what a customer’s AI assistant needs.

What Open GxP Will Look Like

The customer-facing layer we are designing — we call it Open GxP — puts three things in front of the platform’s existing capabilities: proper sign-in, strict separation between customers, and permission checks on everything.

The planned set of around forty tools falls into seven groups:

  • Managing work in progress — see what is running, check status, preview what a change would do, move things forward, manage tasks
  • Documents — list, search, upload, update details, classify for eCTD
  • Audit trail — search audit records, approval history, access history, compliance status
  • Electronic signatures — check status, list signatures, request a signature, verify integrity
  • Regulatory configuration — agencies, controlled vocabularies, eCTD mappings
  • Platform information — what kinds of records exist, what fields they carry, and retrieving them
  • Submissions — list dossiers, read validation reports

An important clarification: this customer-facing layer is in design. It is not live. The internal tooling is in production, and the platform capabilities it will sit in front of are in production. The connecting layer is planned.

The Hard Limits: What AI Cannot Do

In this context, what you prevent matters as much as what you enable. Our design includes limits that are absolute — not policies an assistant could talk its way around, but capabilities that simply do not exist for it:

  • AI cannot sign documents. There is no signing capability available to it. 21 CFR Part 11 requires an electronic signature to be attributable to a specific individual. AI can request a signature, creating something for a person to action, but a person must sign in and sign.
  • AI cannot publish submissions. Publishing sends a submission to a health authority. That is too consequential to happen without a person.
  • AI cannot delete anything. Documents are archived through a proper process, never deleted.
  • AI cannot reach another customer’s information. Which customer it belongs to is determined from its credential, by the platform. There is nowhere for it to ask on behalf of somebody else.
  • AI cannot bypass an approval gate. Where a step requires a signature, the preview reports that a person is needed and the step will not proceed.

How This Compares to Kivo’s Headless GxP

Kivo, a competitor in this space, announced their “Headless GxP” approach in May 2026, with three features planned for private beta in July 2026. Their approach uses the same standard, with a pattern they describe as: AI researches and recommends, a person acts in the application, and Kivo records both.

We think Kivo identified the right standard and the right pattern. Where the approaches differ is in what sits behind it:

  • Depth of what is already built: DnXT has thirty internal tools in production sitting on a full regulatory platform — eCTD publishing, validation, document management, workflow. Kivo’s announcement describes three features entering private beta. These are different stages of maturity, which is a factual difference rather than a judgement.
  • Compliance foundations: DnXT’s audit trail is created by the platform as information is written, rather than added as a separate step, and our electronic signatures are designed for 21 CFR Part 11. Whether Kivo has equivalent foundations is not clear from their public materials.
  • Scope: DnXT is a full regulatory platform including publishing, multi-region validation and document lifecycle. Kivo appears focused on compliance record-keeping. Different scopes serve different needs.

We should also be honest about where Kivo may have the advantage:

  • Simplicity: “Connect your AI to our compliance layer” is a simpler proposition than “adopt our full regulatory platform”. For a company that already has publishing and only needs the compliance layer, Kivo’s approach could fit better.
  • AI-agnostic from day one: Kivo emphasises working with any AI. Our internal tools were built for one assistant in particular, though Open GxP is deliberately designed to work with any.

Both companies are early. This is a new frontier for the entire industry. The question is not which approach is “right” — it is which fits a given organisation’s existing systems and regulatory needs.

Why “Open” Instead of “Headless”

We chose the word deliberately. “Headless” implies decoupled — compliance operating without a user interface. “Open” implies accessible — any AI can connect, whatever the provider. Claude, GPT, Gemini, or something built in-house. The standard is fixed; the choice of AI is the customer’s.

This matters because pharmaceutical companies have varied AI strategies. Some have committed to one provider. Others use several for different jobs. A regulatory compliance layer should work with all of them.

What Comes Next

Our plan has four stages: read-only capabilities first, so AI can look things up and check compliance status; then the ability to move work forward and upload documents; then more advanced capabilities such as requesting signatures and handling regional variants; and finally the developer documentation to support it all.

We will share progress openly as we build. If you are evaluating how AI might fit your regulatory work, we would welcome the conversation — whether DnXT turns out to be the right fit or not.

This article was written by the DnXT Solutions team. We’ve aimed to present both our approach and the competitive landscape honestly. If we’ve gotten something wrong about another vendor, we welcome corrections at se******@***********ns.com.