- Services
SERVICES
- Platform
PLATFORM
- Solutions
AI AGENTS
LIFE SCIENCES AI
TECHNOLOGY
- Industries
INDUSTRIES
- Work
- About Us
CORPORATE
RESOURCES
- Contact us
Parts catalog intelligence is the use of AI to create and maintain spare parts catalogues: extracting part data from mixed format source documents, normalising part numbers and descriptions, mapping components to the vehicle configurations they fit, and producing catalogue output in standardised structures for downstream systems.
The output feeds the electronic parts catalogue that dealers and technicians use to identify and order components. Its accuracy determines whether the right part is ordered first time, which in turn determines return rates, repair completion times, and dealer confidence in the system.
The traditional process is manual data entry and normalisation performed at scale by specialist teams, frequently offshore, working from documentation that was never designed to be machine readable.
Four capabilities, and the second is where most of the difficulty sits.
Format independent extraction. Reading part data from engineering drawings, supplier documents, bills of material, and legacy records without a template configured for each source format.
Part number normalisation and usage mapping. Resolving regional and supplier variations of the same part into a consistent identity, and determining which configurations each component applies to. This is the substantive intelligence in the process, because it requires reasoning about equivalence rather than matching strings.
Standardised catalogue output. Producing structures that downstream electronic parts catalogue systems consume directly, rather than intermediate data requiring further transformation.
Synchronisation across markets. Propagating changes to regional catalogues rather than re-entering them per market, which is what allows global scale without proportional cost.
The measure is time to dealer readiness for a new model or variant, alongside catalogue error rate as observed through incorrect part orders and returns.
Wizr AI’s Global Parts Catalog Intelligence and Automation capability, within its automotive portfolio, covers AI driven catalogue creation and updates, multi-format document ingestion and part data extraction, automated part number normalisation and usage mapping, and EPC-ready catalogue output with standardised structures.
Smart Catalog Synchronisation extends this across global markets, addressing the propagation problem that otherwise makes each additional market a proportional cost rather than a marginal one.
Wizr AI has published a case study on spare part cataloguing transformation for a leading global auto manufacturer. The solutions carry built in governance, traceability, and optional human verification, which matters in catalogue work because an unreviewed error propagates into every dealer order for that part
Pharmacovigilance is the monitoring, assessment, and reporting of adverse effects associated with medicines after they reach the market. Pharmacovigilance automation applies AI to the case processing workload this generates: intake, duplicate detection, coding, seriousness and expectedness assessment, narrative drafting, and regulatory reporting.
The obligation is continuous and the volume grows with every product and market. Reports arrive from healthcare professionals, patients, literature, clinical studies, and increasingly from unstructured channels, in inconsistent formats and varying completeness. Each must be processed to a defined standard within regulatory timeframes that are measured in days for serious cases.
The work is also unusually repetitive for a regulated activity. A large share of case processing is extraction, coding to standard terminologies, duplicate checking, and narrative writing to a template, which is exactly the profile where AI assistance is effective.
The regulatory position is clearer here than in most pharma processes, because safety assessment is explicitly a qualified judgement.
Suited to automation. Case intake from multiple channels, extraction of structured data from unstructured reports, duplicate detection across a case database, coding to standard terminologies, completeness checking against reporting requirements, narrative drafting to template, and tracking of reporting deadlines.
Requires qualified assessment. Causality assessment, seriousness determination where it is not clear cut, medical judgement on expectedness, and signal evaluation. These carry patient safety consequence directly.
Duplicate detection deserves particular mention because it is a genuine weakness of manual processing. The same event reported through different channels, at different times, with different detail, is difficult to identify by search and straightforward to identify by semantic comparison. Failing to detect duplicates distorts the safety database itself, which is a more serious problem than the processing cost.
Pharmacovigilance is one of the four named areas of Wizr AI’s pharma and biotech portfolio, alongside regulatory intelligence and submission automation, compliance and quality operations, and commercial and medical review intelligence.
The design principles that apply across Wizr AI’s regulated work apply here with particular force: traceability, audit readiness, and human review at defined control points. Safety case processing is a context where the division between automated preparation and qualified assessment is set by regulation rather than by risk appetite.
The underlying capability is the same document and correspondence handling that appears elsewhere in Wizr AI’s portfolio, applied to a domain where the accuracy of extraction and the completeness of the record carry patient safety consequence rather than commercial consequence alone.
Pre-built AI agents are agents that ship already configured for a defined business function, with the prompts, workflows, integrations, and data models for that function already in place. An enterprise configures them to its own processes and systems rather than assembling them from platform primitives.
The distinction from a custom agent is where the work sits. Building a custom agent means defining the reasoning, designing the tool set, building the connectors, writing the prompts, establishing the evaluation set, and implementing the governance controls. A pre-built agent for the same function arrives with most of that done, because the underlying process is broadly consistent across organisations even where the specifics differ.
This is why deployment timelines differ so sharply between the two approaches. The gap is rarely in model capability; it is in integration, prompt engineering, and evaluation work that has either already been done or has not.
Pre-built agents are a good fit where a process is genuinely common across organisations, and a poor fit where it is a source of differentiation. Four questions separate the two.
How much of the process is standard? Invoice matching, bank reconciliation, password resets, and order status enquiries follow similar logic almost everywhere. Proprietary pricing logic and specialised clinical workflows do not.
How configurable is the agent? A pre-built agent that cannot accommodate your approval thresholds, escalation rules, and terminology becomes a constraint rather than an accelerator.
Which systems does it already connect to? The pre-built value collapses if the connectors do not cover your actual ERP, CRM, or ITSM instance, because integration is the work that was supposed to be saved.
What governance does it inherit? An agent adopted outside the platform’s permission and audit model creates a governance exception, which is expensive to reconcile later.
The realistic pattern in most enterprises is a mix: pre-built agents for standard high volume functions, custom agents where the process is proprietary, both on the same platform so governance stays uniform.
Wizr AI Assembly is Wizr AI’s pre-built component stack, spanning integration, agent and workflow management, agent libraries, and ready to deploy applications. Wizr AI states that its pre-built applications, including customer experience agents, ITSM agents, and finance agents, supply around 80 percent of the functionality needed to go live, with further customisation reducing deployment time from months or years to weeks.
Two components sit underneath. The Agent Library provides pre-built AI functions to start development from rather than from scratch. The Agent and Workflow Builder supplies ready to use functionality for creating AI powered workflows that integrate with internal applications.
Coverage extends across functional areas including customer support, IT support management, finance and accounting, sales and marketing, recruitment, mortgage assistants, and legal assistants. Because all of them run on the Wizr Enterprise AI Platform, they inherit the same access controls, audit trails, and certifications rather than each carrying its own governance model.
Wizr AI reports a 90 percent pilot to production conversion rate, which it attributes to running pilots on the same governed platform used in production.
Prompt engineering is the practice of writing instructions that reliably produce the output an AI system needs. It covers how a task is described, what constraints and format requirements are stated, what examples are supplied, and how edge cases and refusal conditions are handled.
Its status in enterprise AI has changed. In early deployments prompt wording was the primary lever available, and skill at it produced large differences in output quality. As models have improved at following instructions and as systems have grown to assemble large payloads, phrasing has become one input among several, and usually not the decisive one.
It remains necessary rather than sufficient. A poorly specified task produces poor output regardless of how good the retrieval is. But a well phrased prompt cannot compensate for missing context, and the common enterprise mistake is iterating on wording when the actual defect is that the system was never given the information it needed.
Five, ordered by how much they typically return.
Specify the output format precisely, including structure, length, and what to do when the required information is unavailable. Ambiguity about format produces variance that is expensive downstream.
Define the refusal and escalation condition explicitly. A prompt that does not permit the system to say the material does not answer the question leaves it no option but to produce something.
Supply examples of correct handling, particularly for edge cases. Demonstrating the desired behaviour is generally more reliable than describing it.
Separate instruction from data structurally, using clear delimiters, so content being processed is not interpreted as instruction. This is a security practice as much as a quality one.
Test changes against an evaluation set. The effect of a wording change is frequently not what the author expected, and without measurement, prompt iteration is guesswork that feels like progress.
In production the last point is what separates prompt engineering from prompt fiddling, and it is why prompts belong under version control and review rather than being edited in place.
Wizr AI’s position is that prompts encoding organisational standards are governed artefacts rather than individual craft. Centralised prompt governance is a named component of Glidepath AI SDLC, paired directly with its acceleration claim, since consistent output across teams is what converts individual productivity gains into organisational ones.
The governed prompts draw on the same version controlled single source of truth as code generation, covering coding standards, architectures, and reusable artefacts. Keeping the standards and the prompts that apply them in one place is what prevents the two from diverging over time.
Oversight across projects runs through a multi-project control plane with policy dashboards, and Wizr AI reports a 60 percent reduction in compliance effort and issues from this governance approach.
Prompt governance is the practice of managing prompts as controlled organisational assets rather than as text individuals write ad hoc. It covers versioning, review and approval, central storage, access control, testing before change, and visibility into which prompts are in use where.
The rationale is that an enterprise prompt is not a query. A prompt that instructs an agent how to classify a support case, what tone to use with customers, which standards generated code must follow, or when to escalate is encoding operational policy. Left unmanaged, that policy exists in dozens of slightly different versions across teams, with no record of who changed what or why.
The parallel that clarifies it is configuration management. Nobody would accept application configuration being edited directly in production without version control or review. Prompts determine behaviour just as directly and are frequently treated with far less discipline.
Six controls.
Central storage with version control. Prompts held in a repository with full history, not embedded in application code, scattered across notebooks, or held in individuals’ notes.
Review and approval proportionate to impact. A prompt controlling customer facing behaviour or engineering standards warrants review. An exploratory prompt does not, and requiring the same process for both guarantees the process is bypassed.
Testing before change. Prompt edits alter behaviour in ways that are difficult to predict, so changes should run against an evaluation set before release. This is the control most often absent.
Environment separation. Prompts move through development and staging before production, in step with the code around them.
Usage visibility. Knowing which prompts are active in which systems, so a change can be assessed for blast radius before it is made.
Ownership. A named owner per prompt, since an unowned prompt drifts and nobody notices.
Prompt sprawl is the failure state, and it mirrors agent sprawl. Teams independently write instructions covering the same behaviour, the versions diverge, and the organisation ends up with contradictory encoded policy that nobody has read side by side.
Centralised prompt governance is one of the two named pillars of Glidepath AI SDLC, alongside context engineering. Wizr AI positions it as a core mechanism behind the accelerator’s targeted 40 to 50 percent lifecycle acceleration, on the basis that consistent instructions produce consistent output across teams rather than output that varies by individual prompting skill.
Visibility across an engineering organisation is provided through a multi-project control plane and policy dashboards, which addresses the usage visibility requirement at the scale where prompt sprawl actually develops, meaning across projects rather than within one.
The connection to compliance is direct. Because prompts encode the standards that generated artefacts must follow, governing them centrally is part of why Wizr AI reports a 60 percent reduction in compliance effort and issues. Standards applied through a governed prompt library are applied to every project rather than to the projects whose leads happened to enforce them.
Prompt injection is an attack in which instructions are embedded in content an AI system processes, causing the system to treat them as commands rather than as data. It is the most significant security concern specific to language model applications, and it becomes materially more serious once the system holds credentials and can act.
The mechanism is that a language model receives its instructions and its input in the same channel, as text, and has no reliable way to distinguish the two. Text that looks like an instruction can be interpreted as one regardless of where it came from.
Two variants matter. Direct injection comes from the user, attempting to override the system’s instructions in conversation. Indirect injection is hidden in content the system retrieves or processes: a document, an email, a support ticket, a web page, a code comment. Indirect injection is the more serious case in enterprise deployments, because the attacker never interacts with the system and the malicious content may sit dormant in a knowledge base until retrieved.
The difference is what a successful attack achieves.
Against a chatbot, successful injection produces inappropriate output. That is a content problem.
Against an agent, successful injection produces action, executed under the organisation’s credentials, inside systems the agent is permitted to touch. That is privilege escalation, and it is why prompt injection belongs in a security review rather than a content moderation discussion.
There is no complete defence at the model layer. Instruction and data share a channel, so filtering is probabilistic and attackers iterate. The defences that hold are architectural.
Least privilege above all. An agent that cannot perform an operation cannot be manipulated into performing it. Permission scoping bounds the blast radius regardless of whether the model is fooled.
Treat all retrieved content as untrusted data. Content from documents, tickets, and external sources should never be handled as instruction, structurally rather than by request.
Validate intended actions independently of the model. Check the operation against schema, permissions, and business rules before execution, using logic the model does not control.
Require approval for consequential actions, so a manipulated agent still cannot complete a high impact operation unilaterally.
Log everything, since injection is frequently detected retrospectively through anomalous action patterns.
Adversarial prompt testing is a standard step in Wizr AI’s testing, security, and governance phase before any release is approved, alongside bias evaluation. Probing agents with injection attempts before production is what converts prompt injection from an unexamined risk into a tested one.
The architectural defences sit in the Security component of the platform. Least privilege data access audited to SOC 2 Type II is the control that bounds what a manipulated agent could achieve, and secure data processing maintains confidentiality and integrity at every stage of handling. Continuous oversight through real time monitoring supports the retrospective detection that injection frequently requires.
Configurable human verification at defined control points provides the approval barrier for consequential operations, which is why it matters in pharma and finance workflows specifically.
