Taking a Pharma AI Platform From Prototype to Enterprise Pilot Approval

The short version: a multi-tenant AI platform for pharmaceutical manufacturers was heading into pilots with large pharma organisations. It worked, but it was functional rather than production-ready. Over 7 weeks and 4 milestones I ran 26 security checks, fixed both critical and all four high findings, hardened the platform and its infrastructure, and handed over the operating procedures. All 24 of 24 acceptance criteria passed, and the platform was approved for enterprise pilot deployment with pharmaceutical clients.

I worked as fractional CTO and security architect on a fixed-price, milestone-based statement of work, delivering every change as a pull request. The client is anonymised and the evidence is under NDA, so nothing here links to it. The evidence table says how each claim was verified and where it lives.

The Starting Point: The Gaps

The platform reads manufacturing and quality documents, runs root cause analysis and answers questions through a RAG chatbot over pgvector. Each customer is a tenant. Before a pharma buyer would put its data in, these gaps had to close:

• Access tokens lasted 7 days. A stolen token meant a week of access to sensitive manufacturing data.
• Cross-tenant access. One tenant could read another tenant’s documents.
• No central logging, alerting or health checks.
• No audit trail, no traceability for AI calls, and no compliance path.
• Kubernetes pods ran as root, and access control was undocumented.
• No load testing, no tested backup and restore, no disaster recovery procedure.

What Was Checked

The assessment was 26 pass/fail checks following OWASP methodology, across the Django application, the API, the Kubernetes deployments on EKS and the AWS account around them. On top of that I scanned container images with Trivy and infrastructure code with Checkov, verified encryption at rest and in transit, tested tenant isolation across the API, and looked at the AI layer specifically: what goes into the model, what comes out, and whether anyone could reconstruct a given answer afterwards.

The checks found 2 critical, 4 high and 3 medium issues. The two critical ones were the token lifetime and the cross-tenant document endpoint.

What Was Found and Fixed, by Milestone

Milestone 1 - Application security and observability (weeks 1-2)

• Access tokens cut from 7 days to 8 hours, one work shift. Short enough to defend to a security team, long enough that users are not logging in every hour.
• The cross-tenant document endpoint fixed with entity-scoped query filters, so a document request only ever returns the caller’s tenant’s data.
• Public API documentation (Swagger and ReDoc) removed from production.
• 7 HTTP security headers added at the NGINX layer.
• 8 CloudWatch alarms covering security and infrastructure, application log groups with retention, and health and readiness endpoints for Kubernetes probes.

Milestone 2 - EKS and AWS hardening, data protection (weeks 3-4)

• 6 Kubernetes deployments hardened: run as non-root, all Linux capabilities dropped, privilege escalation disabled, RuntimeDefault seccomp profiles.
• 0 critical findings in the Trivy container scans.
• An access-control matrix documented, with admin access limited to named accounts.
• Encryption verified for object storage, the database at rest, and TLS in transit.
• Tenant isolation tested across all API paths. A separate isolation gap in the RAG pipeline’s vector store was identified and documented for the client.

Milestone 3 - Audit trail and AI/LLM security (weeks 5-6)

• An audit trail covering 12+ critical actions - authentication events, document changes and AI queries - with a request ID carried through every service, and logs kept append-only for 365 days. I chose CloudWatch here because individual log events cannot be edited or deleted, which is the property a pharmaceutical buyer asks about.
• Input guardrails for prompt injection, role manipulation, jailbreak attempts and data-exfiltration patterns, and output guardrails for personal data and credentials or secrets, validated by 15+ test cases. Each guardrail can block or only log, so sensitivity could be tuned in production without a deploy.
• Every model call traced to its tenant, user and request, with latency and token counts.
• A compliance gap memo mapping the platform against SOC 2 Type II, ISO 27001 and FDA 21 CFR Part 11. It is a gap memo: it says which technical controls exist and what is still missing. It is not a certification.

Milestone 4 - Load testing, disaster recovery and handover (week 7)

• Load tested at the pilot target of 5 concurrent users: 0.98% error rate, with all the statement of work’s targets met. Autoscaling configured for the application, frontend, workers and cluster.
• Backup and restore drilled: about 45 minutes end to end, against a target of under an hour. Kubernetes rollback validated at under 2 minutes.
• 10 operational runbooks, including CPU, database, Redis, certificates, nodes, workers, guardrails and rollback.

What It Took to Get to Pilot Approval

Most of the fixes were not difficult. What got the platform approved was that every one could be shown. Each milestone had written acceptance criteria in the statement of work - 24 in total - and each was closed with evidence: a pull request, a scan result, a test run, a drill log. Delivery was pull-request only: 17+ pull requests, 7 of them in the first milestone, and no change reached the codebase any other way.

A few decisions mattered more than the rest:

• Harden the existing tenant isolation rather than rewrite it. A move to database row-level security was the riskier change to make before a pilot. Tightening the entity-scoped filters and then testing every API path closed the hole.
• Use CloudWatch instead of adding a third-party APM: no marginal cost, and most of what an APM would have given.
• Make the guardrails configurable. A guardrail that blocks too much gets switched off. A switch between logging and blocking lets sensitivity be tuned against real traffic.

The platform went from “functional but not production-ready” to approved for enterprise pilots in 7 weeks.

Evidence

None of this evidence is public. The client is under NDA, so the table says how each claim was verified and where the evidence sits, rather than linking to it.

What This Does Not Claim

• No certification. The platform is not SOC 2, ISO 27001 or 21 CFR Part 11 certified on the strength of this work. The memo identifies gaps; a formal audit or validation is a separate step for the client and an accredited auditor.
• No penetration test. This was a structured security and architecture assessment, not an adversarial test by a specialist firm.
• Not every finding was fixed. The critical and high findings were. I do not claim the same for the three medium ones, for every Checkov finding, or for the vector-store isolation gap, which was documented rather than closed.
• Pilot scale, not production scale. The load test was at the pilot target of 5 concurrent users.
• The evidence is private. You are taking these figures from me, not from a public artefact.

Who This Is Relevant For

AI SaaS teams in the UK, US and Europe who are about to put a regulated buyer’s data into a multi-tenant product - pharma and life sciences especially - and have a pilot, a security questionnaire or a procurement review between them and the contract. The platform is usually fine. What is missing is tenant isolation someone has tested, an audit trail, guardrails on the model, and evidence for each.

The shorter version of this work is the AI security and architecture review: the same checks and a prioritised list of fixes, from £3,500 over 1-2 weeks. If you need someone to stay and fix things as well, as here, that is a fractional AI CTO engagement.

Request a security review →

Related reading: the LLM security checklist lists the checks behind an assessment like this one; multi-tenant RAG isolation covers the vector-store gap; prompt injection defence for RAG covers the input guardrails; what to log in an LLM audit trail covers milestone 3; and validating an LLM system under 21 CFR Part 11 covers what comes after a gap memo.