What Configuration and Access-Governance Record Should Exist Before a Veeva Vault AI Agent Is Approved for GxP Use?

AI-assisted research and drafting · Practitioner reviewed by Rohith Karanam Sreedhar · 24 September 2026

ⓘ Library content is researched and drafted with AI assistance and reviewed by a Navata practitioner before publication. For original analysis and long-form practitioner perspectives, visit Navata Insights →

Direct answer

Before a Veeva Vault AI Agent is approved for GxP use, the configuration record should identify the actual Vault objects and boundaries that define the deployed agent: Agent name/class and status; Veeva-provided or custom LLM connection and model where knowable; Agent User and its Security Profile; objective; configured context; each agent action and its instructions; assigned agent tools; chat and API exposure; and the permissions that govern what the agent can read or change. The approval should show that these settings are consistent with the intended use and risk classification, and should define which configuration changes trigger re-approval. This record governs what the agent is configured and authorised to do; it does not replace separate performance validation of its outputs.

Veeva's current custom-agent architecture is more explicit than a generic "AI service identity" model. A custom agent is configured from named Vault objects and settings: the Agent itself, an objective, one or more Agent Context records, Agent Actions with instructions, optional Agent Tools, a Veeva-provided or custom LLM connection, and a system-managed Agent User that is created or assigned when the agent is activated. Custom LLM connections currently support documented AWS Bedrock, Azure AI Foundry and Google Cloud combinations in addition to Veeva-provided connections. That makes the pre-approval record a configuration-governance artefact: it should describe the actual deployed Vault configuration rather than an abstract AI architecture. LIB-013 and LIB-028 already set the general framework for intended use and GxP risk, while LIB-055 addresses output assurance; this reference focuses on whether the configured agent matches those decisions before use.

Identify the deployed Agent and LLM connection

Record the specific Agent name, class, status and business purpose, and whether it is standard, system-managed or custom. For a custom agent, record which LLM path it uses: Veeva-provided Basic or Advanced connection, or a custom LLM connection. Where a custom connection is used, capture the provider, configured model identifier and connection record; Veeva's July 2026 documentation lists supported custom connections across AWS Bedrock, Azure AI Foundry and Google Cloud. Where the exact underlying model behind a Veeva-provided connection is not exposed to the customer, record that fact rather than inventing a model/version claim. The approval record should also say how model or connection changes will be detected and assessed later.

Record context, actions, tools and exposure separately

Do not collapse "what the agent can see" and "what the agent can do" into one access statement. Record the Agent Context that supplies document or object data and content; the Agent Actions users or processes can invoke; the instructions attached to each action; and every Agent Tool assigned to an action. Tools matter because they can let an agent action interact with Vault functionality rather than only return text. Record whether each action is exposed in Vault AI Chat, hidden from the action list but still routable, or exposed through the Vault API. Those are separate execution surfaces and should be approved deliberately. Where Tool Evaluation is configurable, record whether tool use is Auto or Required because that changes how execution is initiated.

Treat the Agent User as the execution identity

When a custom agent is activated, Vault creates or assigns a system-managed Agent User. Veeva states that the Agent User can execute agent actions without a user at the keyboard and that its Security Profile is one of the fields customers can edit. Actions performed without a keyboard user are logged as performed by the Agent User; actions initiated by a user through Vault AI Chat are logged as the Agent User on behalf of the keyboard user. The approval record should therefore identify the Agent User, its Security Profile and any groups or roles that affect its effective permissions, then compare that effective access with the context, actions and tools the agent is intended to use. The important question is not whether the agent has a generic service account; it is whether this specific Agent User can read or change more than the approved use requires.

Version-control objectives and action instructions as configuration

A custom agent's objective and each Agent Action's instructions are natural-language configuration that shapes execution. Record the objective, the instruction set for every approved action, and the associated context and tools in the approved baseline. A material change to an objective, action instruction, context definition, tool assignment or exposure setting should be treated as a configuration change even where no code or model changes. Keep prior approved baselines retrievable so a reviewer can reconstruct what governed the agent on a given date.

Require an explicit, accountable approval

The configuration record should carry approval from someone accountable for the GxP process the agent will support, not only a record that an administrator completed the technical setup. That approval should confirm that the Agent class and objective, context, Agent User permissions, actions, tools, chat/API exposure and LLM connection are consistent with the intended use and risk classification already established under LIB-013 and LIB-028. The approver is accepting a defined configuration baseline, not approving "AI" in the abstract.

Define what should trigger re-approval

An approved configuration is not permanently approved. Define in advance which changes reopen the approval: a change to the Agent class or primary object/document type; a different LLM connection or model identifier where visible; a material change to the objective, context or action instructions; addition or removal of an Agent Tool; a change to Agent User permissions; a change to chat or API exposure; or a change from an answer-only pattern to one capable of creating, updating or otherwise acting on Vault records. This is a configuration-governance rule derived from the system's actual change surface. Whether a particular use also falls within EU AI Act high-risk obligations is a separate legal classification question and should not be inferred merely from the fact that the agent is used in a GxP process.

Sources

Veeva Systems, Configuring Custom Agents: current Vault Help for Agent configuration, custom LLM connections, Agent Users, Agent Context, Agent Actions, Agent Tools, chat/API exposure and audit behaviour.
Veeva Systems, Vault AI.
European Commission, EudraLex Volume 4, Annex 11: Computerised Systems.

Navata practitioner view

I would ask for the Agent User first, then the list of Agent Actions and Tools. If the approval record talks extensively about the model but cannot show which Security Profile the Agent User had, which tools were assigned, whether an action was exposed through API, or which instruction text was in force, it has documented the technology and missed the executable configuration. I would compare the Agent User's effective permissions with the approved context and actions, then inspect one action that can write or trigger workflow behaviour and ask what evidence proves that capability was deliberately authorised. I would also ask for the previous approved objective/instruction baseline after a change, because a natural-language edit that changes what an agent does is still a configuration change even when no code was deployed.