When you compare pharma automation companies for manufacturing or quality work, test their evidence rather than their product claims. The regulated manufacturer stays accountable for the system whoever builds it, so a partner is only as good as the evidence it leaves you with. This guide is the selection view within our wider coverage of AI in the pharmaceutical industry.
One scope note first. Pharma automation also covers hospital and retail pharmacy automation: dispensing robots, medication cabinets, pharmacy management software. This page is not about those. It is for teams buying automation, computerised systems or AI for drug manufacturing and quality operations, where Annex 11 and Part 11 apply.
A checklist for comparing pharma automation companies
In short form, each row pairs a test with the evidence to ask for and the warning sign to watch. The rest of the guide explains why each row matters and what a weak answer looks like.
| What to test | Evidence a credible partner can show | Warning sign |
|---|---|---|
| GxP validation experience | Validation plans and executed test scripts from past regulated work | Talks about features and accuracy but has no documented lifecycle process |
| Quality system | A quality management system you can assess, as Annex 11 asks of the regulated user | Answers a questionnaire but declines an audit |
| Formal agreements | Willingness to sign a quality agreement that names who does each regulated activity | A contract clause saying the system is “GMP compliant”, with no responsibilities defined |
| Part 11 language | Describes features that let you meet Part 11 once you configure, validate and operate the system | Claims the product is “Part 11 compliant” |
| Audit trail | Who, what, when and why recorded, locked on, reviewable | Audit trail optional, editable or switched off by default |
| Release evidence | A component inventory with exact versions for each release you validate | Version ranges or “latest” in the build |
| Exit | A written exit strategy returning records, metadata, audit trails and configurations | No written exit strategy for system data |
Why a vendor’s validation package is not enough
The UK MHRA’s 2018 data integrity guidance says that accepting vendor-supplied validation data in isolation from the system’s configuration and the user’s intended use is not acceptable, because vendor testing outside your process and infrastructure is likely to cover functional verification only and may not meet performance qualification.
FDA’s General Principles of Software Validation says the same from the other side: a manufacturer may use its own staff, the vendor or a consultant to validate, but it retains ultimate responsibility that the software is validated for its intended use and performs as intended in its application. That guidance is written for medical device software, yet the revised Annex 11 draft states the same principle for pharma: relying on a vendor’s qualification leaves the regulated user fully responsible.
The practical consequence is that you write your own requirements. The revised Annex 11 draft states that the regulated user should establish and approve a user requirements specification whether the system is built in-house, bought off the shelf or delivered as a service, and that a vendor’s specification should be reviewed, approved and owned by the user. A partner worth hiring will push you to do this early instead of offering its own document as a substitute. If you want the mechanics of that lifecycle, our explainer on GxP validation for pharma software covers it.
Vendor evidence reduces your validation work; it never replaces your accountability for it.
What supplier assessment evidence should a pharma automation vendor provide?
Annex 11, in its 2011 text that is still in force, sets out supplier requirements in a few clauses. Clause 3.1 requires formal agreements whenever third parties provide, install, configure, integrate, validate, maintain or modify a computerised system or related service. Clause 3.2 makes the competence and reliability of a supplier key selection factors and bases the need for an audit on a risk assessment. Clause 4.5 asks the regulated user to ensure the system was developed under an appropriate quality management system and to assess the supplier appropriately. Clause 3.4 adds that supplier quality and audit information should be made available to inspectors on request.
GAMP guidance supplies a recognised framework for meeting those requirements. ISPE’s GAMP training frames the regulated user’s and supplier’s roles as assessment, cooperation and the leveraging of supplier activities and documentation, inside a risk-based lifecycle using ICH Q9 quality risk management and GAMP software categories. Leveraging is the important word: an assessment determines whether supplier documentation is leveraged rather than repeated.
How deep the assessment should go
Depth follows risk, not the vendor’s marketing category. A system integrator configuring workflows and migrating records, an AI model supplier, a cloud host and a support desk with remote access all need assessment, at different depths. A few rules hold across them:
- A completed questionnaire does not justify approving a high-risk service; where key evidence is missing, record the uncertainty and the rationale for any residual risk.
- For an initial qualification, APIC’s supplier guide for API manufacturers (2024) highly recommends an on-site audit by your own qualified auditors with subject-matter experts, not a remote, paper-based or third-party audit, unless the supplier was previously audited.
- Quality agreements are mandatory for highly critical services, and a supplier reluctant to sign one should trigger a re-evaluated risk assessment and mitigation.
- SOC 2 or ISO 27001 reports are inputs to the review, and their scope, period and GxP gaps still need checking.
FDA’s device software validation guidance is blunt about uncooperative vendors: some have no documented lifecycle that can support your validation, some will not permit an audit, and where validation information is unavailable you need system-level black-box testing, which for many applications is not sufficient on its own. In selection terms, a vendor that refuses an audit has left you to cover the gap with system-level testing and may make the product unsuitable for your use. Weigh that before price.
Audit-trail and release evidence you should expect at handover
MHRA defines the audit trail as metadata recording the “who, what, when and why” of creating, changing or deleting a GxP record without overwriting the original. Changes should be attributable to a named person, dated and time-stamped, with the reason recorded. Audit trails identified as required should be switched on, users should not be able to amend or disable them, and any administrator action on them should itself be recorded. Annex 11 adds that audit trails need to be available, convertible to an intelligible form and regularly reviewed.
The 2025 Annex 11 revision draft sharpens this: it asks for the user’s role, the old and new values, recording at the time of the event rather than the end of a process, and audit trail functionality enabled and locked at all times. A partner building new automation now should design to that stricter text.
Two further handover items complete the picture. Shared logins should not be used on systems holding GxP data, and MHRA expects GMP sites with programmable logic controllers to show progress towards individual login and audit trails. Release evidence matters as much as runtime evidence: a GxP supplier audit of software asks about release and change records, an exact component inventory per release, and the quality agreement. Because you validated one specific version, the inventory for that version has to stay retrievable after later versions ship, and unpinned dependencies in the build count as an uncontrolled change.
Finally, the exit. The revised Annex 11 draft lists, among the contract terms for a service provider, an exit strategy by which the regulated user retains control of system data and the right to test new versions before release. MHRA asks that contracts with cloud providers secure timely access to data, metadata and audit trails for you and for regulators, and define archiving and readability for the full retention period.
The draft status of the revised Annex 11 and the new Annex 22
Treat the new EU texts as drafts, not law. The revised Annex 11, the revised Chapter 4 and a new Annex 22 on artificial intelligence went to stakeholder consultation from 7 July 2025 to 7 October 2025; they remain drafts, and the 2011 Annex 11 is the text auditors cite today. The European Commission describes the drafts as prepared by the EMA GMDP Inspectors Working Group with PIC/S, strengthening supplier oversight, data integrity, audit trail and security controls.
A partner that quotes draft Annex 22 clauses as binding requirements is misreading their draft status. The sensible position is to build to the 2011 text and make the draft expectations easy to meet.
Testing an AI engineering partner for GxP work
ISPE’s GAMP Guide: Artificial Intelligence builds on GAMP 5 Second Edition and its Appendix D11, and gives specific guidance on supplier assessment and monitoring for AI-enabled systems, data and model governance, and ongoing monitoring with live data.
Draft Annex 22 sets requirements that reach supplier-built models. Documentation of training, validation and testing should be available and reviewed by the regulated user whether the model is built in-house or by a supplier. Acceptance criteria are set by a process subject-matter expert and approved before testing, and should be at least as high as the performance of the process the model replaces. Test data must be kept independent of training, and the model, its system and the process go under change control before deployment. As drafted, the annex covers static, deterministic models and states that generative AI and large language models should not be used in critical GMP applications.
So ask a prospective AI partner how it keeps test data independent. GSK’s automated visual inspection case study (PQRI, 2023) flags the risk that splitting one physical defect kit between training and test can put similar images in both sets and bias the evaluation, which is why it used a separate defect set for testing. Ask, too, who controls the model artefact: with a vendor-hosted model behind an API, weights and system prompts can change on the provider’s schedule, so change control becomes a contractual question. FDA’s 2023 CDER discussion paper on AI in drug manufacturing, which is explicitly not guidance, notes that existing quality agreements with third parties may have gaps in managing AI risks.
The requirements themselves are covered in our piece on what GxP compliance requires for AI software in pharma. Which use cases to fund first, and how each one gets validated, is the subject of our guide to validated AI use cases in pharma manufacturing. One point from that guide matters for selection: waiting for regulatory clarity that is already available is itself a delay pattern in pharma AI adoption. Supply chain systems carry their own compliance questions, which our article on AI for pharmaceutical supply chain visibility takes up.
Specialist AI engineering partner or established automation vendor?
No regulator text answers this one, so what follows is judgement. An established automation vendor with a standard product suits a well-defined, repeatable process (packaging line control, a standard manufacturing execution or data historian system) where its validation package covers most of what you need and your job is configuration and intended-use testing. A specialist engineering partner suits work where no product fits: a custom inspection model on your defect types, a model that must run on-premise behind your firewall, or an integration across instruments and data systems that nobody sells off the shelf. The GSK case reflects one version of that trade-off, choosing on-edge deployment on GMP infrastructure for data integrity and access control while accepting more validation effort.
Either way, the tests above are the same. The difference is that with custom work you own more of the documentation, so the partner’s lifecycle discipline matters more than its product roadmap.
Who can build validated AI and automation for a pharma site?
TechnoLynx builds computer vision systems, including anomaly detection, and GPU engineering, and assembles approval evidence packs for auditors and regulators.
TechnoLynx does not suit buyers who need quality-unit approval, validation sign-off, a turnkey packaging line or an off-the-shelf MES; its work is AI and GPU engineering for life sciences.
The question that decides most selections
Every criterion here reduces to one test: when an inspector asks why a record changed, or how a model was shown fit for use, can you answer from your own files without phoning the vendor? The revised Annex 11 draft puts it directly, asking that documentation for outsourced activities be accessible and explainable from your facility. A partner that leaves you able to do that has done the job; one that leaves you dependent on its goodwill has not, whatever its product does.
FAQ
Which pharmaceutical company is using AI technology?
GSK is one documented example: its 2023 PQRI case study describes deep-learning models for automated visual inspection, validated in desktop OQ, on-line PQ against a manual inspection baseline, and lifecycle stages under change control.
