AI for teams that run trials, from people who built the systems trials run on.

Nothing leaves your control. Training runs in the model accounts your organization has already approved, under your enterprise agreement, so the vendor terms you negotiated are the terms that apply. We do not bring our own accounts for participants to use, and we do not take copies of your documents home. When we build an application, the data stays in your tenant and we work inside it. If your organization has no approved platform yet, that is the first conversation in an implementation engagement, and we will not run a training day on consumer accounts against real study data.

Whichever ones your organization has approved. We teach the idea, not the tool: how to hand a task to a model, give it what it needs, and check what comes back. That works the same in Claude, ChatGPT, Gemini, or Copilot, and it is why the training holds up when the tools change. A year ago most of our sessions ran on ChatGPT and Gemini; today our own operation runs mostly on Anthropic’s Claude models, and that is what we recommend when a client has no preference and the work involves long documents and careful instruction following.

For a build, the model is a component we choose against the task. The design, the prompts, the checks, and the run guides are what you own, and they are written so the model can be swapped without rebuilding the application.

Training is priced per day, per cohort, with a cap on room size so every participant builds. Application development is scoped as a fixed-price build with a defined deliverable, then an optional monthly maintenance retainer once it is in production. Implementation work is a short assessment followed by a fixed-scope program, and we will tell you in the assessment if you do not need the program. Ask for numbers on the call; we would rather quote against your situation than publish a rate card that does not fit it.

The same way any other tool does: by being explicit about what the AI produces and who is accountable for it. In a GxP context we treat model output as a draft that a qualified person reviews and signs, never as the record itself. The controlled record stays in your validated system, with its audit trail, its electronic signatures, and its access controls untouched. Our governance work writes that position into an SOP so it is not left to individual judgment, and our builds keep a log of prompts, versions, and outputs so a reviewer can reconstruct how a draft was produced.

It depends on what it touches. An agent that drafts an internal brief from public information is a productivity tool and does not need computer system validation. An application whose output feeds a GxP decision or record needs a risk-based assessment, and usually the answer is to keep the model out of the critical path: the model drafts, a person decides, and the decision lands in a validated system. Where a build does need formal qualification, we deliver requirements, test evidence, and a traceability matrix in the format your quality group already uses. We spent twelve years on the vendor side of IRT and eClinical systems, including inspection and audit support, so this is familiar ground.

You do. Code, prompts, configuration, and documentation are delivered into your repositories and your accounts. We keep no license over them and no lock-in. The maintenance retainer exists because models change and your process changes, not because you cannot run the application without us.