- Intelligence as a Service (IntaaS) means using the capabilities inside a pharmacovigilance AI platform, such as checking validity, suggesting coding or validating an E2B (R3) file, one at a time, from your own systems.
- There are two ways in: a REST API for your systems, and an MCP server for your AI assistants and agents.
- A capability is more than a model. It brings your rules, the knowledge it needs and the evidence behind every answer.
- The marketing authorisation holder stays responsible for the safety process. The service has to make that responsibility easier to carry, not harder.
Most safety organisations are not starting from a blank page. They have a safety database, validated workflows, partner agreements and a team that knows how the process runs. Many are also building their own AI assistants. When AI for pharmacovigilance comes up, the question is often not “which platform should we move to?” but “can we use the intelligence without moving at all?”
Intelligence as a Service is the answer to that question. This explainer covers what it is, the two ways to use it, what a usable answer must contain, and what stays with you.
What “intelligence” means here
A pharmacovigilance AI platform is made of capabilities: classify an incoming document, check whether a report meets the four minimum criteria for a valid case, look for duplicates, extract case data, suggest MedDRA codes, determine reportability by market, validate an E2B (R3) message. On a platform these run inside one workflow. As a service, each one can be called on its own, where your process needs it.
It is tempting to think of a capability as “a model behind an API”. In a regulated process that is not enough. A useful capability brings four things together.
- Models read documents and propose an answer.
- Rules encode your SOPs and the regulatory requirements, so the answer is checked against them before it is returned.
- Knowledge includes the MedDRA version you use, your product dictionary and your coding conventions.
- Evidence is returned with every answer: the source text, the rule applied, the model version and a trace that links to the audit trail.
Two ways in: APIs and MCP servers
A REST API is the familiar route. Your own code decides when to call a capability, sends a request and receives a structured response. It suits systems: an intake portal that classifies and checks every new report, a workflow tool that asks for suggested coding, a submission step that validates a file before it is sent.
An MCP server is the route for AI assistants and agents. The Model Context Protocol (MCP) was introduced by Anthropic in November 2024 as an open standard for connecting AI assistants to the systems where data lives. In December 2025 it was donated to the Agentic AI Foundation, a directed fund under the Linux Foundation. Under the specification, an MCP server can offer three kinds of feature:
- Tools: functions the AI model can execute, such as
check_validityorsuggest_coding. - Resources: context and data for the user or the model, such as your SOP rules or the MedDRA version in use.
- Prompts: templated messages and workflows, such as an approved instruction for summarising a case for medical review.
Messages use JSON-RPC 2.0 between hosts (the AI applications), clients (connectors inside them) and servers (the services that provide context and capabilities).
| REST API | MCP server | |
|---|---|---|
| Who calls it | Your systems, from code you write | An AI assistant or agent, when it decides a tool is needed |
| Best for | Fixed steps in a workflow | Assistants that support people, and agent workflows |
| What you build | The integration and the workflow around it | The agent, its scope and how people review its work |
| What comes back | Result with evidence | The same result with the same evidence |
The two routes should never give different answers. If a validity check through the API says one thing and the same check through an MCP tool says another, neither can be trusted. One engine behind both is the simplest way to avoid that.
What a usable answer contains
A capability that returns only “valid: true” leaves your team to rebuild the reasoning, and leaves your inspector with nothing to look at. A usable answer carries its own evidence.
| Part | What it holds | Why it matters |
|---|---|---|
| Result | The structured answer | Your system or agent can act on it |
| Evidence | Source text, page and line for each value | A reviewer can check it in seconds |
| Rule | The SOP or regulatory rule applied, with its version | Shows why, not only what |
| Confidence | How sure the engine is, against your thresholds | Decides whether a person reviews it |
| Routing | Accept, or send to a person | Keeps human oversight where your SOP requires it |
| Trace | Model version and trace ID | Links the answer to the audit trail |
This is not decoration. In the US, 21 CFR 11.10(e) requires secure, computer-generated, time-stamped audit trails for operator entries and actions that create, modify or delete electronic records. The CIOMS Working Group XIV report on AI in pharmacovigilance, published on 4 December 2025, sets out seven guiding principles, including human oversight, transparency and explainability, and governance and accountability. An answer that names its sources, rule and version is how a service supports those expectations inside your process.
Where it fits in a case’s life
A service does not replace your workflow. It sits inside it, at the steps where it helps, and it hands back to your people where it should.
Two things decide where a person reviews the answer: your SOP, which may require review for certain steps or case types, and confidence, which routes uncertain answers to a person regardless. Both should be configurable, and both should be visible in the evidence.
What stays with you
Using intelligence as a service does not move regulatory responsibility. The marketing authorisation holder remains responsible for its pharmacovigilance system, including the parts that use a service.
| The provider | You |
|---|---|
| Versioned capabilities with release notes | Your workflow and the decisions made in it |
| Validation evidence for each version | Validation of your own integration and use |
| Evidence and trace with every answer | Acting on routing signals and review gates |
| Security, data protection and service levels per agreement | Your submissions and your regulatory obligations |
Regulators are moving in the same direction. EMA’s reflection paper on AI in the medicinal product lifecycle was adopted in September 2024. FDA’s January 2025 draft guidance proposes a risk-based framework for establishing the credibility of an AI model for a defined context of use. Both put the emphasis on the user knowing what the AI is for, how it was checked and how it is overseen.
Questions to ask any provider
- Does every answer include its sources, the rule applied, the model version and a trace ID?
- Do the API and the MCP server run on the same engine and return the same answer?
- Can we set our own confidence thresholds and review gates, and see them applied?
- How are new versions released, and can we choose when to move?
- What validation evidence comes with each version?
- What can an AI agent never do through the MCP server, and where is that enforced?
- Where is our data processed and stored, and what is it used for?
- How do we move from the service to a full platform later, if we want to?
How to start
Pick one capability where the effort is high and the rules are clear. Validity checks and literature screening are common choices. Run it in a sandbox on sample data, then in parallel with your current process on live work, and compare. Measure what matters to you before you start, so the result is evidence rather than opinion. Then widen the scope one capability at a time.
vGenix Ai offers its module intelligence this way, as REST APIs and vGenix MCP servers running on GenixOS. See the Intelligence as a Service catalogue.
Sources
- Anthropic, Introducing the Model Context Protocol (25 November 2024)
- Anthropic, Donating the Model Context Protocol and establishing the Agentic AI Foundation (9 December 2025)
- Model Context Protocol, Specification (overview, features, and security and trust and safety)
- 21 CFR 11.10, Controls for closed systems
- CIOMS Working Group XIV, Artificial Intelligence in Pharmacovigilance (report published 4 December 2025)
- Sagittal, “AI in PV: what the CIOMS WG XIV report means in practice” (list of the seven principles)
- EMA, Artificial intelligence (reflection paper, LLM guiding principles, AI workplan)
- NSF summary of FDA draft guidance, Considerations for the Use of AI to Support Regulatory Decision-Making for Drug and Biological Products (January 2025)