How to Add AI to LabWare LIMS On-Prem Without Moving Data

LabWare stores its operational data in a relational database, typically Oracle or SQL Server. The core entities are samples, tests assigned to a sample, and results entered for each test, alongside configuration tables for products, analyses, specifications, lists and users. Because LabWare is highly configurable, the exact columns differ between sites, so treat any table name in a blog post as a starting point and confirm it in your own data dictionary.

LabWare also exposes business logic through LIMS Basic, its scripting language, and through the integration interfaces licensed with your version, including web services in current releases. Use those when you need the application to apply its own rules, for example to create a sample. For analytics-style questions, a direct read from a replica is faster, cheaper on the production system and easier to audit.

Documents are the other half. SOPs, methods, COAs, deviation reports and instrument printouts are usually attached to records or stored on a document system. They need their own retrieval index, because a language model cannot answer 'what does the method say about hold times' from result tables.

A lab assistant that ignores security is worse than none. LabWare restricts users by security group and by what they may see or edit, and many sites segment by lab, product or customer. The tool server must carry the end user's identity into every query and add the equivalent filter, rather than running as one all-powerful service account and trusting the model to hold back.

In practice that means a mapping table from LabWare groups to row filters (lab, product family, project), applied inside the views or the query builder, plus per-chunk access tags on the document index. Test it the way an auditor would: sign in as a restricted user and try to extract another lab's results by rephrasing the question.

Regulated labs should also keep the assistant out of any decision path. Its answers are navigation and summary, not a reportable result.

A lab with 50 to 300 named users asking a few questions each per day usually fits on one or two data-center GPUs with a 14B to 70B class open-weight model, plus a small embedding model on CPU or a slice of GPU. A document index of 20,000 to 200,000 pages is a few gigabytes. Use the sizing calculator to turn your numbers into ranges.

Roll out in three phases over roughly 8 to 16 weeks: read-only questions on curated views, then summaries and drafts with human review, then a small set of approved actions. Pick five to ten real questions from supervisors first and measure accuracy against them.

Limits are real. The model is weak at long numeric reasoning, so push calculations into SQL or code. Heavily customized schemas need more mapping work. If your only need is a canned dashboard or a LabWare report, the built-in reporting is enough.