Letter from our CTO

Workflows, automation, and AI.

Coordinating validation steps, approvals, and governed records—while using large language models in a stateless way that does not train on your data. Here, orchestration means workflow and lifecycle coordination—not generic infrastructure or DevOps scripting.

The question we hear most often in security reviews and vendor questionnaires is whether an LLM is learning from customer validation data. That concern is reasonable given how many products treat the model as the product and quietly blur where data goes.

“Is the LLM learning from our data?”

The short answer is no: we use models in a scoped, disposable way over your governed system of record, not as a shared brain that retains or trains on your content. For a concise page you can forward to IT or quality, see Is the LLM learning from our data?.

Intelligence lives in your data, not in the model

Many AI products assume the model is the system: you pour data in, fine-tune, and over time the weights encode your world. In GxP work that raises an obvious problem—your risk rationale, failure modes, and proprietary process narrative should not become part of a vendor's opaque parameter space. At Valkit.ai we inverted that assumption. Your records, relationships, and workflow state in your tenant are the source of truth. An LLM, when enabled, reasons over that context for a single request. It does not store it, learn from it across time, or build an internal memory of your organization. What reviewers approve and release still traces to governed data they can inspect, not to model state they cannot.

Operationally, each call follows the same pattern: read the minimum necessary data from your database, build a specific prompt, return a result, and finish. Nothing is retained by the model for reuse; nothing is shared across customers. When your data or process changes, outputs change because the system of record changed—not because we retrained something on a schedule.

We did not want validation intelligence to sit inside a black box. When someone asks why a statement reads a certain way, the answer has to land in requirements, tests, risk, and change history—not in “the model preferred that wording today.”

Same product with or without an LLM—and not chat-first

You can use Valkit.ai with all AI features disabled.

If you turn AI on, you can use your large language model (LLM) or ours—we are LLM-agnostic. Toggling those features does not fork the product into a “lite” version: workflows, structure, and evidence behavior stay the same; what changes is how much drafting and assembly runs behind the scenes. That matters when policy shifts, procurement adds constraints, or one division wants everything off while another adopts AI.

If you connect a model you trained or fine-tuned yourself— including on your own data—training data, retention, and how you explain that model to auditors are yours to define. You can pair our workflow and system-of-record design with a model that reflects your own training choices; our standard commitments about customer data and third-party models speak to how we run the platform and our offered models, not to replacing your governance for a model you supply.

We have also been deliberate about not making chat the core interface. Validation programs run on protocols, approvals, trace, and change control. Teams need the system to already understand what a package is, what “done” means, and how objects connect—without re-explaining the world in a prompt box on every screen. Smart automation and structured workflows come first; the model fills complexity, speeds tedious steps, and improves wording where it helps, usually without calling attention to itself. The compliment we want is that you shipped faster and reviewers could follow the thread—not that the UI felt like a consumer chatbot.

A separate failure mode we watch for is “AI everywhere” as a thin layer: fluent text that drifts from requirement IDs, controls, and evidence your package is actually built on. Governed AI can still be disconnected AI if it is not mechanically driven by the same objects and state your quality system trusts. We keep AI tied to live system state—no reliance on stale exports or pre-baked narratives that fall out of date after the next change order.

Orchestration, control, and AI-first engineering

Orchestration is an easy word to skim past, so let me be explicit: in our usage it is not DevOps job scheduling or generic “glue.” It is the platform knowing where a package sits in its lifecycle, which transitions are valid, when human review is mandatory, and how outputs land back as structured records linked to requirements and evidence. That coordination is what makes AI usable in production—the model may propose or phrase; the workflow decides what is allowed, what gets stored, and what happens next.

Because we are LLM-agnostic and stateless in how we call models, you retain practical control: which provider you standardize on, how you satisfy infosec on retention, and how you explain to legal and quality that one customer's context does not train another's experience. Trust, in our view, comes from architecture you can inspect more than from louder marketing disclaimers.

Calling Valkit.ai AI-first refers to engineering: data flow and extension points for models were part of the design from the start, not a chat window bolted onto a generic validation tool six months later. The spine of the product remains structured, deterministic, and grounded in real data; AI runs through that spine instead of asking people to abandon it and prompt their way through compliance work.

Keep intelligence in the data. Use AI to unlock it—not replace it.

The industry is still experimenting with where AI belongs in regulated systems; experiments that go wrong land on audits, CAPAs, and patient safety. We bias toward fewer magic tricks and more defensible mechanics—narrow automation where it earns its place, without turning the product into a stage for AI theater.