When most people read the headline about Michael Polansky, Lady Gaga's partner and a former top deputy to Sean Parker, funding a startup that keeps living human skin alive outside the body, the story understandably gravitates toward celebrity and biotech hype. But strip away the name recognition and you're left with a genuinely hard engineering problem: how do you turn a piece of living tissue into a reliable, observable, auditable data source for machine learning?
The real breakthrough isn't the petri dish-it is the real-time data pipeline that turns living tissue into a production ML service. Anyone who has shipped a model to production knows that clean, labeled, continuously available data is harder to build than the model itself. Add the constraint that your data source can die, age. And respond unpredictably to its environment. And you have one of the more interesting edge cases in modern MLOps.
Polansky's reported platform sits at the intersection of tissue engineering, microfluidics, computer vision. And AI-driven compound screening. For senior engineers, it's worth studying not because of who founded it. But because it pushes data infrastructure, observability. And compliance into a domain where milliseconds and microliters both matter,
From Static Assays to Living Data Pipelines
Traditional skincare and dermatology research relies on static assays: two-dimensional cell monolayers, animal models. Or ex vivo tissue slices that are imaged once and discarded, and these approaches generate small, low-resolution datasetsA living-tissue platform changes the paradigm by keeping human skin biopsies viable for days or weeks, continuously perfusing them with nutrients, exposing them to candidate compounds. And capturing time-series data from sensors and cameras.
For software engineers, the analogy is moving from batch ETL jobs to streaming event pipelines. Instead of exporting a CSV after a fixed interval, the system emits a constant stream of telemetry: temperature, pH, dissolved oxygen, transepithelial electrical resistance (TEER). And high-resolution microscopy. The AI model doesn't train on a snapshot; it trains on a movie. That shift demands a fundamentally different architecture, one that looks more like IoT fleet management than a conventional data science notebook.
Read our guide to building streaming data pipelines for regulated environments The ingestion layer likely combines time-series databases such as TimescaleDB or InfluxDB with message queues like Apache Kafka or MQTT brokers for device telemetry. Image data. Which can dominate storage, typically lands in object storage such as S3 with metadata catalogs powered by Apache Iceberg or Delta Lake. The schema isn't just "compound X caused effect Y"; it's "compound X, at concentration Y, on donor Z, in incubator W, at hour T, under camera settings V, produced morphological change U. "
The Living-Tissue Compute Substrate Is Non-Deterministic
Here is the challenge that keeps platform engineers up at night: living tissue is non-deterministic infrastructure. A GPU doesn't change its behavior because it was cultured on a Tuesday. But a skin biopsy might. Donor age, ethnicity, body site, sun exposure. And hormonal state all introduce variance. If the training data isn't carefully stratified and annotated, the model will learn donor-specific artifacts rather than compound-specific biology.
In production environments, we have seen similar issues with edge devices deployed in variable physical conditions. A camera exposed to direct sunlight produces different embeddings than one in shade. The fix is usually environmental normalization, calibration drift detection, and domain adaptation. In a wet-lab setting, that translates to rigorous donor metadata, batch-level controls. And statistical process control on every bioreactor.
Another parallel is hardware failure, and servers fail; tissue diesThe platform must treat donor samples as ephemeral compute nodes. Redundancy, sample pooling, and graceful degradation become first-class design concerns. If a biopsy shows signs of necrosis, the system should flag it, quarantine the data. And reallocate the experimental slot rather than silently poisoning the training set.
Computer Vision Meets Living Human Skin
Computer vision is where much of the AI value is captured. High-content imaging systems take repeated photographs or volumetric scans of the living tissue. The engineering team then runs segmentation models to identify epidermal layers, hair follicles, keratinocytes, and inflammatory markers. Over time, the model learns to correlate subtle morphological changes with compound efficacy or irritation.
This isn't a one-shot classification problem, and it's a spatiotemporal forecasting problemThe model must track how structures evolve over days, not just label a single frame. Architecturally, that points toward video understanding models, recurrent or state-space backbones. And sometimes graph neural networks if the team is modeling cell-cell interaction. Explore our deep get into computer vision pipelines for scientific imaging
Data labeling in this domain is expensive. Pathologists or dermatologists may need to review time-lapse imagery to establish ground truth. Active learning becomes essential: the model identifies the most informative frames or compounds, human experts label them. And the loop repeats. Tools like Label Studio, V7, or custom CVAT deployments are common here, integrated with MLflow or Weights & Biases for experiment tracking.
MLOps Challenges With Biologically Active Datasets
Standard MLOps assumes that you can version a dataset, reproduce a training run. And redeploy a model. Biological data breaks several of those assumptions. You can't always re-run an experiment on the exact same piece of skin. Once a biopsy is consumed, the sample is gone. That immutability constraint makes data lineage and artifact provenance critical.
Teams typically address this with data versioning tools like DVC or LakeFS, combined with strict metadata schemas. Every training example needs a pedigree: donor ID, harvest date, media lot, incubator ID, imaging run. And preprocessing script version. When an auditor or scientist asks, "Why did the model predict irritation for compound 734? " the answer must be traceable through every transformation back to the raw microscope file.
Model drift detection is also different. In typical SaaS ML, you watch for input distribution drift or prediction drift. In bio-ML, you also watch for biological drift: are the current donor tissues aging faster than the training population? Are the sensors drifting out of calibration, and are media formulations subtly differentThis calls for a multi-layer monitoring stack that separates instrument drift from biological variance from model decay.
Observability and SRE for Wet Lab Systems
If you have ever managed a production service, you know the vocabulary: SLIs, SLOs, error budgets, on-call runbooks. The same concepts apply to a living-tissue platform, except your "service" is a piece of human skin in a perfused chamber. A reasonable SLO might be "tissue viability above 90 percent for at least 14 days, measured by TEER and lactate dehydrogenase release, across 95 percent of bioreactors. "
SLIs are drawn from the sensor stream, and tEER, pH - oxygen saturation, glucose consumption,And image quality metrics all become time-series signals. Alerting rules in Prometheus or Grafana trigger when a chamber deviates from its expected envelope. The on-call response isn't a code deploy; it's a wet-lab intervention-replacing media, recalibrating a pump. Or terminating a compromised sample before it corrupts an experiment.
The observability stack also needs to capture lineage for every manual action. Who changed the perfusion rate, and who added a compoundWho approved the donor batch? Immutable logs, sometimes backed by tamper-evident stores like immudb or Sigstore-style attestations, make this defensible under regulatory scrutiny. RFC 3339 timestamps should be mandatory for every event; without canonical time, cross-system correlation collapses.
Compliance, Audit Trails. And 21 CFR Part 11
Any platform that hopes to support FDA-submission-grade skincare or therapeutic claims must operate under Good Laboratory Practice (GLP) and possibly Good Clinical Practice (GCP). FDA guidance on 21 CFR Part 11 governs electronic records and signatures, which means every data point, every model artifact. And every approval action must be attributable, legible, contemporaneous, original. And accurate-the ALCOA principles.
Engineering for compliance isn't a checkbox; it changes how you design databases and APIs. You can't allow hard deletes. And you cannot overwrite records in placeAudit trails must be queryable and exportable. User authentication should use strong identity providers, and role-based access control must separate operators who run experiments from reviewers who sign off on them. If the platform uses machine learning to make compound-selection decisions, the model itself becomes a controlled record, versioned and locked at the point of use.
Validation is another engineering discipline often overlooked by software teams. Computerized systems in regulated labs require Installation Qualification, Operational Qualification, and Performance Qualification (IQ/OQ/PQ). That means test scripts, evidence, and sign-offs for the control software, not just the biology. Treating the software stack with the same rigor as the wet-lab protocol is what separates a research prototype from a commercial platform.
Data Ethics and Donor Consent Architecture
Human tissue isn't a synthetic dataset. Every biopsy comes from a person with rights, identity. And expectations about how their biological material is used. The data architecture must therefore encode consent boundaries. Can this donor's tissue be used for AI training, or only for a specific compound screen? Can images be shared with partners? What happens to the data if consent is withdrawn,
These questions have engineering answersConsent can be modeled as a policy attached to donor metadata, enforced at query time. Attribute-based access control (ABAC) or policy engines like Open Policy Agent can gate downstream use. Data retention jobs must respect consent expiration dates. And when tissue is de-identified, the team must follow HIPAA and Common Rule standards for coded or anonymized specimens.
Bias is another ethical concern with a technical footprint. If the training data over-represents skin from certain ages, ethnicities. Or body sites, the model may underperform for underrepresented groups that's not merely a fairness issue; it's a product-safety issue for skincare. Teams should stratify datasets, report demographic parity metrics. And design validation cohorts that reflect real-world diversity.
What Software Engineers Can Learn From This
Even if you aren't building a bio-ML startup, the architectural patterns are transferable. First, design for feedback loops, not batch jobs. The most valuable systems combine sensing, inference, and actuation. In manufacturing, that's Industry 4. In skincare research, it's a closed loop between microscopy, AI,, and and microfluidic compound dosing
Second, treat environmental context as first-class data. A prediction without metadata about how it was produced is rarely actionable. Whether you're logging request latency under load or tissue viability under perfusion rate, context determines whether the number is meaningful.
Third, build defensibility through provenance, not just accuracy. Regulators, customers. And partners increasingly demand to know how a model was trained and how a decision was made. Investing in lineage, auditability. And reproducibility early pays dividends when the platform scales or faces scrutiny. Learn how we design compliant cloud infrastructure for regulated startups
The Broader Shift in AI-Driven Biology
Polansky's project is part of a larger trend: AI is moving from digital content into the physical and biological world. We see similar convergence in synthetic biology - drug discovery, agriculture. And materials science. The common thread is that software teams must now model domains with noisy, dynamic,, and and ethically sensitive data sourcesSuccess depends less on novel neural architectures and more on robust data engineering, observability. And governance.
Organ-on-a-chip research published in Nature Reviews Drug Discovery shows how microfluidic tissue models can accelerate compound screening while reducing animal use. The next decade will likely see these platforms become standard preclinical infrastructure. The teams that win will be the ones that treat biology as a software problem: instrumented, automated, versioned. And relentlessly observable.
For Denver-based engineering teams and startups, this is also a talent opportunity. The skills that matter-streaming data architecture, MLops, computer vision, regulated cloud infrastructure. And embedded control systems-are exactly the skills needed to build the next generation of AI-driven biology platforms. Whether your domain is skincare, therapeutics. Or precision agriculture, the engineering playbook is converging.
Frequently Asked Questions
What does it mean to train an AI model on living skin?
It means collecting continuous data from human skin tissue kept alive outside the body, then using that data to train machine learning models. The model learns to recognize how the tissue responds to different compounds, environments. Or stimuli over time, rather than relying on static images or dead samples.
How is this different from traditional skincare testing?
Traditional methods often use two-dimensional cell cultures, animal models. Or single-time-point tissue samples. A living-tissue platform captures longitudinal, high-resolution data from tissue that behaves more like real human skin. That produces richer training data and can reduce the need for animal testing.
What software stack supports a living-tissue platform?
Typical components include streaming telemetry ingestion through Kafka or MQTT, time-series storage in TimescaleDB or InfluxDB, image storage in S3 with Delta Lake or Iceberg metadata, computer vision pipelines in PyTorch or TensorFlow, and MLOps tooling such as MLflow, Kubeflow. Or Weights & Biases. Observability layers use Prometheus, Grafana, and structured logging.
What are the main MLOps risks with biological data?
The biggest risks are non-determinism - limited reproducibility, sample mortality, donor variance. And biological drift. Ground-truth labels are expensive and slow to obtain. Data lineage, careful stratification, and drift detection are essential to keep models accurate and defensible.
How does regulatory compliance change the engineering approach?
Regulated work requires immutable audit trails, electronic signatures, role-based access control, validated software systems, and strict data provenance. Teams must design databases and APIs so that records can't be silently altered and every model artifact can be traced back to its source data and training configuration.
Conclusion and Next Steps
The story behind Michael Polansky's startup is ultimately an engineering story. Keeping living skin viable is impressive, but the harder and more valuable achievement is building the data and control plane that makes that tissue useful for AI. From streaming telemetry and computer vision to MLOps lineage and regulatory compliance, the platform touches nearly every discipline in modern software engineering.
If your team is building a regulated bio-ML product, mobile companion app. Or IoT-controlled lab instrument, the architecture decisions you make today will determine whether you can scale tomorrow. We help engineering teams design cloud-native, compliant. And observable platforms for exactly these kinds of problems. RFC 4122 UUIDs and RFC 3339 timestamps are small details, but they're the kind of details that make an audit passable and a pipeline reproducible.
Contact our Denver engineering team to discuss your bio-ML platform - mobile interface. Or data infrastructure project. We can help you move from prototype to production without losing the rigor your science deserves.
What do you think?
Should living biological systems be treated as "infrastructure" with uptime SLOs,? And what changes when the compute substrate can literally die?
How should MLOps frameworks adapt when ground-truth labels take days or weeks to generate from wet-lab assays?
What data governance patterns are needed when training data comes from human donors rather than digital events?
