AI Reference Architecture for a 500-Person Biotech (Not a Top 20 Pharma)

Why a 500-Person Biotech Needs a Different Architecture

The architecture that works for a top-20 pharma does not work for a 500-person biotech for several specific reasons. First, the platform engineering capacity is smaller. A top-20 pharma might have hundreds of engineers dedicated to AI platform work; a 500-person biotech might have five or ten. Designing an architecture that assumes the larger capacity produces an architecture that the smaller organization cannot operate.

Second, the regulatory perimeter is tighter. A 500-person biotech typically does not have the staff to run separate compliance disciplines for each AI capability; the perimeter has to be designed to be defended by a small team. Architectures that distribute compliance responsibility across many capabilities work poorly at this scale.

Third, the time horizon is shorter. A 500-person biotech typically has a milestone cadence of twelve to eighteen months; architectures that require multi-year buildouts to deliver value are misaligned with the organization’s operational rhythm.

Fourth, the capital is more constrained. A 500-person biotech rarely has the capital to fund multi-year platform investments without operational pressure. Architectures that depend on sustained heavy capital investment without near-term value delivery are unaffordable.

Fifth, the scientific focus is narrower. A 500-person biotech typically has a defined platform thesis or therapeutic focus. The AI architecture has to support that specific focus rather than a generalized capability set. As DriveNets’ analysis of AI infrastructure for pharma and biotech notes, the compute and storage requirements for biotech AI work are significant but can be calibrated to the specific use cases the organization needs.

The cumulative effect is that the architecture has to be deliberately smaller, deliberately more focused, and deliberately less ambitious than the published patterns suggest. The discipline is in resisting the temptation to import patterns designed for larger organizations.

The Five Layers Worth Owning

The reference architecture for a 500-person biotech can be expressed as five layers, each with deliberate scope limitations. The layers, from foundation to applications, are: data, identity and access, model, application, and governance.

The deliberate scope limitations are the operationally important feature of the architecture. A 500-person biotech that tries to build all five layers at the scope a top-20 pharma would build them will discover, two years in, that the platform team cannot keep up and that the capabilities have begun to decay. The discipline is in choosing scope that the team can sustain.

The Data Layer: Where Most Programs Stumble

The data layer is the foundation of the architecture and the layer where the largest number of programs stumble. The stumbles are recognizable: data scattered across systems with no canonical source, no data dictionary for AI use cases, no lineage tracking for regulated data, no defined refresh cadence, and no agreed ownership for data quality issues.

The data layer that a 500-person biotech should build has five specific characteristics.

An organization-controlled primary store for AI inputs. The data that flows into AI capabilities should live in an organization-controlled store, not in vendor systems. This is the single most consequential architectural choice for preserving optionality and managing compliance.

Documented data dictionaries for each AI use case. The data dictionary specifies what data the use case consumes, what its quality expectations are, and what its handling requirements are. The dictionary is the foundation of validation; without it, validation work cannot proceed reliably.

Lineage tracking for regulated data. Data that flows through regulated AI capabilities has to maintain lineage from source to AI input to AI output. Lineage is a 21 CFR Part 11 expectation extended to AI; the organization has to be able to demonstrate where the data came from and how it was transformed.

Defined refresh cadence and data drift monitoring. AI capabilities consume data that evolves over time. The architecture has to include monitoring that detects when input data has drifted in ways that affect AI performance.

Clear ownership for data quality. Every dataset feeding an AI capability needs an owner who is accountable for its quality. Programs that distribute ownership across multiple roles without clear accountability consistently find that data quality issues do not get resolved because nobody owns the resolution.

The data layer is unglamorous compared to the model layer, but it is the layer that determines whether the rest of the architecture functions. As the consensus across pharma leaders documented in Sakara Digital’s AI readiness roadmap for pharma indicates, data foundations are the non-negotiable precondition for AI to scale safely.

The Model Layer: Buy First, Build Selectively

The model layer for a 500-person biotech should default to buy, with selective build where the scientific differentiation justifies the investment. The buy-first posture has several specific implications.

Foundation models from major providers. The biotech should not be training foundation models. It should be consuming them from major providers (OpenAI, Anthropic, Google, AWS, Azure) through their enterprise APIs, with the API access tied to the data layer through controlled integration.

Specialist biotech AI through partnerships. Where the biotech needs specialized AI capabilities tied to its scientific platform — target identification, molecular design, biomarker discovery — partnerships with specialized providers (such as the Recursion or Tempus class of specialist vendors) deliver the capability without the in-house build cost.

Limited fine-tuning where scientifically differentiating. Where the biotech has proprietary data that produces meaningful improvement when used to fine-tune a foundation model, fine-tuning is the right intermediate path between pure consumption and pure build. The fine-tuning investment should be tied to specific use cases that have demonstrated value, not pursued speculatively.

Vendor-provided MLOps for vendor-provided models. The MLOps infrastructure for consumed models should come from the vendors themselves. Building MLOps infrastructure to manage models the organization did not train is a category of investment that 500-person biotechs cannot sustain.

Documented model inventory and lifecycle. Even with a buy-first posture, the organization needs an inventory of the models it uses, their providers, their version pinning, and their lifecycle status. The inventory is the foundation of compliance and the basis for vendor management.

The buy-first posture is sometimes resisted by engineering leaders who advocate for in-house model development. The advocacy is usually well-intentioned and sometimes scientifically sound, but the math rarely works for a 500-person biotech. The in-house build cost dominates the value delivered until the organization is materially larger.

The Application Layer: Workflow-Embedded, Not Standalone

The application layer is where AI capabilities meet the people using them. The architectural choice that distinguishes successful from unsuccessful programs at this scale is the choice between workflow-embedded and standalone applications.

Workflow-embedded. AI capabilities are integrated into the existing tools users already use — the document management system, the eTMF, the LIMS, the regulatory submission platform. Users do not have to adopt a new tool; the AI shows up where their work already happens. Workflow embedding is harder to implement than standalone applications, but it produces much higher adoption and much better outcomes.

Standalone. AI capabilities are accessed through new applications that users must adopt. The application has its own interface, its own login, its own learning curve. Standalone applications are easier to build but consistently produce lower adoption and less consequential outcomes.

The 500-person biotech should default to workflow-embedded AI almost universally. The exceptions are narrow: capabilities so novel that no existing workflow accommodates them, or capabilities whose primary user base does not have an existing tool to embed into.

Workflow embedding has several specific implementation requirements. The AI capability has to integrate cleanly with the host application, which often requires API access the host vendor charges for. The AI’s outputs have to be presented in the host application’s conventions, which often requires custom UI work. The audit trail has to span both the AI and the host application, which often requires deliberate logging design. None of these are trivial, but they are all tractable; they are the work that workflow embedding requires.

The Governance Layer: Lightweight But Real

The governance layer for a 500-person biotech should be lightweight enough to operate with the available staff but real enough to satisfy regulatory expectations. The discipline is in scoping the governance to what is needed without expanding to what is theoretically desirable.

The minimum viable governance layer has six elements.

An AI use case inventory. Catalogues every AI capability in use, their owners, their risk tier, their validation status, and their compliance posture. The inventory is the foundation of inspection readiness; without it, every other governance discipline is compromised.

A tier classification SOP. Defines how AI use cases are classified by risk, including criteria for high-impact versus low-impact uses, the validation expectations for each tier, and the approval pathway for new use cases.

A lightweight validation methodology. Articulates the validation work each tier requires, with templates that operationalize the methodology. The methodology should be extensions of the existing CSV discipline, not parallel AI-specific disciplines.

A defined incident response procedure. Articulates how AI-related incidents are triaged, escalated, and remediated. The procedure should integrate with the existing quality incident process rather than running alongside it.

A change control integration. Vendor-driven AI updates flow through the existing change control process, with AI-specific augmentations for assessing material versus minor classifications.

A cross-functional steering committee. Cross-functional governance with QA, IT, scientific leadership, and regulatory representation. The committee owns tier classification, validation approval, and significant change decisions. It does not need to meet weekly; monthly cadence is typically sufficient at this scale.

The six elements together produce a defensible governance posture without requiring a dedicated AI governance organization. As the scale grows, the elements expand and additional elements are added; at 500-person scale, the minimum viable version is adequate and the maximum sustainable version. As IntuitionLabs’ 90-day pharma AI readiness diagnostic framework articulates, the governance disciplines that matter most at this stage are the ones that can be sustained, not the ones that look most ambitious.

The Evolution Path as the Organization Grows

The reference architecture for a 500-person biotech is not static. As the organization grows, the architecture needs to evolve. The evolution path is recognizable.

At 500-1,000 employees, the architecture should focus on consolidating the data layer, deepening the workflow embedding, and maturing the governance discipline. The model layer should remain predominantly buy with selective build; the application layer should remain workflow-embedded.

At 1,000-2,500 employees, the architecture should begin to invest in MLOps infrastructure for the in-house fine-tuned models that have proven their value. The data layer should mature into a more sophisticated data fabric with cross-platform integration. The governance layer should expand to include a dedicated AI governance function with deeper subject matter expertise.

At 2,500+ employees, the architecture begins to resemble the patterns published for larger organizations. In-house model development becomes feasible for differentiating use cases. The platform engineering team becomes large enough to operate the more sophisticated patterns published by NVIDIA, the major cloud providers, and the consulting firms.

The discipline of the evolution path is in not skipping stages. Programs that try to deploy 2,500-employee architectures at 500-employee scale consistently fail because the platform team cannot operate them. Programs that try to defer the architecture entirely until they reach 2,500-employee scale consistently fail because the foundations were not built when they were needed. The right posture is to operate at the scale appropriate to the current size and to invest deliberately in the next stage as the organization approaches the threshold.

The platform team sizing question

One specific operational question that 500-person biotechs face is platform team sizing. The general guideline that works in practice: the platform team should be sized at roughly 1.5% to 2.5% of the total organization for the foundational architecture, growing as the AI portfolio matures. For a 500-person biotech, this implies a platform team of approximately seven to twelve people across data engineering, MLOps, AI application engineering, and governance support.

The team should be deliberately cross-functional rather than siloed. The data engineer who builds the data layer needs to understand how the model layer will consume the data. The AI application engineer needs to understand the governance requirements that shape the application layer. The governance support staff need to understand the technical architecture they are governing. The cross-functional discipline produces better outcomes than the siloed alternative, particularly at this scale where any specific role is sized for one or two people.

The make-or-break question of executive sponsorship

A final consideration that determines whether the architecture succeeds: sustained executive sponsorship. AI architecture investments at 500-person scale are large enough to matter and small enough to be deprioritized when other priorities emerge. Programs that have sustained executive sponsorship through the multi-year build can produce architectures that compound; programs that lose sponsorship at the eighteen-month mark consistently produce architectures that decay.

The executive sponsorship has to be specific. Generic enthusiasm for AI is not sufficient; the sponsor has to be willing to allocate platform engineering capacity, to defend the architecture against feature requests that would compromise it, and to maintain investment when other priorities emerge. The sponsor is typically the CIO, CTO, or CSO depending on the biotech’s structure. The choice of sponsor matters; the sustained engagement matters more.

One pattern that consistently produces durable sponsorship: the sponsor is briefed quarterly on architecture decisions that have been made and on the tradeoffs those decisions involved. The briefing is not a request for approval; it is a transparency exercise that keeps the sponsor genuinely informed and able to defend the architecture publicly. Sponsors who are surprised by architecture decisions consistently withdraw support when difficult moments emerge; sponsors who have been kept informed continue to advocate even when other priorities compete. The discipline of the quarterly transparency briefing is small overhead with outsized return on sponsorship durability, and quality leaders building toward sustainable AI capability should make the briefing a non-negotiable element of the platform team’s operating rhythm.

References & Sources