§ 01 · AI WORKFLOW PREFLIGHT FOR REGULATED SYSTEMS
Is this workflow appropriate?
Clarity before execution.
Todaypharma GMP preflight
Nextmedtech (EU MDR + FDA) · the EU AI Act high-risk regime · see Coverage →
Preflight: the checks an AI workflow has to pass before it goes live in a regulated process. Named for the routine a pilot runs before takeoff.
Every Preclari output is a PIF bundle (Preflight Interchange Format): structured JSON plus a human-readable brief, anchored against the cited regulations and signed by hash. PIF is an open spec, Apache 2.0.
Example · today's v0.1 corpus (pharma GMP)
AI triage of quality deviations in a GMP environment. Preclari identifies Annex 11 validation requirements, missing change control for prompts, and audit trail expectations before the pilot begins.
Describe your AI workflow once. Preclari reads it and returns:
which regulations apply,
which controls you're missing,
a PIF bundle (JSON + a human-readable brief) a human auditor can sign, independent of the model that designed the workflow.
A structured review of an AI workflow before you put it into a regulated process, modelled on the routine a pilot runs before takeoff.
What it is
A pre-deployment review of an AI workflow in a regulated environment, run before pilot or production. It names the regulations that apply to your workflow, the controls you already have, the controls you're missing, and the verification steps an auditor can independently run. The output is an artifact you can hand to QA, not a meeting note.
Why "preflight"
Borrowed from aviation. A pilot runs a fixed checklist before takeoff, not because anything is necessarily wrong but because the time to find problems is on the ground. The same logic applies to an AI workflow before it touches a regulated process: catch the missing change-control record, the unrecorded risk basis, the absent audit trail while the workflow is still on paper, not after the regulatory finding.
Why before, not after
Finding a missing control after a pilot is expensive: rework, paused deployment, sometimes a deviation report of its own. Finding it before is cheap: a paragraph in a workflow description. Preclari moves the cost of governance from "after the QA finding" to "before the first run."
What it is not
Not a regulatory chatbot. Not a compliance search engine. Not a regulator. Preclari surfaces what to think about; the regulatory judgment stays with your QA, RA, CSV, model-risk, or compliance function.
Who needs it
Quality, regulatory affairs, CSV, model-risk, and compliance functions evaluating an AI workflow before sign-off. AI implementation teams who want a defensible answer before the QA review, not after. Consultants who put their name on a deployment.
The cost of finding something wrong in the air is far higher than finding it on the ground.
§ 03 · WHO THIS IS FOR
Built for four readers.
Find yourself first. The technical sections that follow are written for these four roles, with one targeted section each below.
01
AI implementation leads
Need a defensible preflight before QA review, not after.
Block the PR when a required control is missing above medium risk.
Most regulatory tools answer "what does this rule say?" Preclari answers "is this AI workflow appropriate?"
Regulatory intelligence platforms are document-first. They index rules, redlines, and guidance, and they help a regulatory affairs professional find the right paragraph. That is not the same job as evaluating whether an AI workflow you are about to deploy belongs in a regulated process at all.
Preclari is workflow-first by design. You describe the workflow (what the AI does, where it runs, what it touches), and Preclari returns the applicable requirements, the controls you have not documented, the assumptions it made on your behalf, and the verification steps a human reviewer can run independently. The output is an artifact, not a search result.
Preclari names the rules that apply, the controls you're missing, and the verification steps a reviewer can run. Every conclusion shows its reasoning chain back to your workflow.
The output is a PIF bundle (JSON + a human-readable brief), openable by a reviewer without Preclari installed. Portable by design; you are never locked in.
Preclari answers one question (is this AI workflow appropriate?) across the AI-touching regulatory wave. v0.1 ships the pharma GMP corpus. Medtech and the EU AI Act high-risk regime are in active onboarding. The architecture, the PIF schema, and the reasoning pattern are the same.
v0.1 · onboarded
Pharma — GMP and adjacent
Today's corpus. Covers AI workflows in GMP environments: deviation triage, batch record review, OOS handling, change control, computerised systems validation.
Example workflow: AI triage of quality deviations → preflight names Annex 11 validation requirements, missing change-control records, ALCOA+ audit-trail expectations.
Onboarded sources
EudraLex Vol 4 (Annex 11, Chapters 1 & 7) · ICH Q9, Q10 · FDA 21 CFR Part 11 + Data Integrity cGMP Q&A · MHRA data integrity · PIC/S PE 009 · WHO TRS 1033 Annex 4.
Active onboarding · trigger-gated
Medtech — EU MDR + FDA medical devices
Smallest cognitive distance from pharma capability. Risk-based validation, post-market surveillance, complaint handling, and PRRC sign-off paths transfer directly. AI-enabled medical devices fall under the EU AI Act's Annex I high-risk track — full obligations there apply August 2027, not August 2026 (which is the Annex III timeline).
Example workflow: AI-assisted Software-as-a-Medical-Device classification → preflight names MDR Article 10 manufacturer obligations, Annex XIV clinical evaluation gaps, and the PRRC sign-off path.
In scope (EU primary)
EU MDR (Regulation 2017/745) — Articles 10, 83–87, Annexes I, II, III, XIV. EU IVDR (Regulation 2017/746) for in-vitro diagnostics.
Supporting (US + UK + international)
US FDA 21 CFR Part 803 (adverse-event reporting), 21 CFR Part 820, the Quality Management System Regulation (QMSR); the QMSR final rule (89 FR 7496) amends Part 820 to incorporate ISO 13485:2016 by reference from 2 February 2026. MHRA Medical Devices Guidance (UK CA path). IMDRF (SaMD framework, MDSAP audit programme; MDSAP is operated by participating regulators, not IMDRF directly).
Annex III · enforcement Aug 2026
EU AI Act — high-risk systems
Full obligations on Annex III high-risk AI systems (standalone, including financial-services creditworthiness assessment) apply from August 2026; Annex I product-embedded systems are on the August 2027 track. Preclari produces an Article 6 + Annex IV-aware PIF artifact ahead of deployment, naming the high-risk classification basis, the Article 9 risk-management posture, the Article 10 data-governance steps, and the Article 14 human-oversight design. Financial services is the entry point (Annex III §5(b) creditworthiness assessment), where existing model-risk governance dovetails with PIF output.
Example workflow: AI-assisted credit decisioning under AI Act Annex III §5(b) → preflight names the Article 6 classification basis, the Article 9 risk management posture, the Article 10 data governance steps, and the Article 14 human oversight design.
In scope (EU primary)
EU AI Act (Regulation 2024/1689) — Articles 6, 9, 10, 11 + Annex IV, 12, 13, 14, 26, 72; Annex III categories including §5(b) creditworthiness assessment. EBA Guidelines on loan origination and monitoring (EBA/GL/2020/06) §4.3.4 on automated models in credit decisions. EBA Report on Machine Learning for IRB credit risk models (EBA/REP/2023/28). ECB Guide to Internal Models. EU DORA (Regulation 2022/2554) co-applies on operational resilience.
Supporting (US parallel)
NIST AI Risk Management Framework — complement, not substitute. Gives a single PIF that addresses both regimes for buyers with EU exposure.
EU regulations are primary for marketing and onboarding sequence; non-EU jurisdictional depth (FDA, MHRA, IMDRF, NIST) is onboarded alongside as the international supporting set. The full corpus state — onboarded, in active onboarding, and on the roadmap — is on the Coverage page.
§ 07 · WHERE IT FITS
In the design loop, not the audit loop.
Preclari is a tool the team that builds the workflow runs against itself, not a tool QA runs after the fact. The artifact lands in QA's hands already.
01 SDLC
In your design template
Add preclari.assert_preflight as a step in your AI-workflow design template. Block the PR when missing_controls has a required entry at risk ≥ medium. The preflight artifact lives next to the workflow definition.
02 CLIENTS
Reference MCP clients
Compatible with Claude Desktop, VS Code, Cursor, and any MCP-aware agent runtime. No bespoke SDK to learn. Your existing agent calls Preclari's typed tools directly during workflow design.
03 CI
As a build step
Wire the CLI into your pipeline. The preflight bundle is committed alongside the workflow YAML; reviewers see what Preclari saw on each commit.
// hand-off rules the agent enforces against its own draftif risk_class == "high"and human_gate == "none": refuse_to_finalise()if any(c.criticality == "required"for c in missing_controls): recommend_pause_pilot()if clarifying_questions: escalate_to_human("answer_first")
In practice Today, your agent in Claude or Cursor can call Preclari during workflow design and refuse to finalise a workflow that lacks required controls above medium risk.
Time-to-first-preflight: under a day. Workflow description (10 minutes), first run (1 minute), reviewer brief on the same hash.
§ 08 · SURFACES
Built for agents, audited by humans.
The same artifact has two faces. An agent reads the structured object; a reviewer reads a printed brief. Both reference the same hash.
Agent surface · MCP
For the model that builds the workflow.
Preclari exposes a typed MCP server with composable preflight tools. The model that designs your workflow can call project_requirements or identify_missing_controls directly and receive a deterministic, hash-stable assertion before any human is involved.
// during workflow design, the agent self-checks▸ tool: preclari.project_requirements input: { workflow_id: "wf_qd_triage…" }◂ response · 200applicable_requirements: ["EU-GMP-Annex-11","MHRA-DI-2018","Swissmedic-CS-Note-2023"]missing_controls: 6applicability_basis:"workflow.data_touchedincludes 'batch_record'"
Human surface · Brief
For the reviewer who signs the deployment.
The same assertion renders as a printed-document-style Preflight Brief. A regulatory affairs lead can read it, mark findings, and sign. The hash on the brief matches the JSON the agent received.
// reviewer marks each finding · Preflight Brief · Draft
Quality Deviation Triage
wf_qd_triage_2026_001 · medium risk
Findings (excerpt)
Annex 11 · User Requirements Specification not documented
Annex 11 / Swissmedic · risk-based qualification plan absent
ALCOA+ · AI output attribution not preserved in deviation record
Reviewer
Date
Same hash, two readers: the agent that builds the workflow, and the human who signs it.
§ 09 · OPEN SPEC
Open by design.
Every Preclari output is a PIF artifact, Preflight Interchange Format. PIF is an open JSON specification published under Apache 2.0, with three schemas: WorkflowDescription, PreflightAssertion, and PreflightSession.
If Preclari ever disappears, your audit artifacts remain readable. Any tool that implements the spec can produce a PIF bundle; any reviewer can verify one. You are never locked in.
PIF is a portable artifact, not a vendor format. Compliance and audit platforms can consume a PIF document as hash-stable, citation-anchored evidence of AI-workflow preflight; the spec is the integration surface. Preclari is the AI-preflight layer; what sits below it stays your choice.
Every workflow change produces a new PIF bundle with its own hash and corpus snapshot. The artifact is the unit of repeatability, not the run.
Not disclaimers. Columns. Every PIF assertion has to declare what it inferred, what would change the answer, and what it deliberately ignored before it ships.
assumptions_made: what we inferred when your description was incomplete; each one removable by you.
clarifying_questions: what would change the output if you answered it.
out_of_scope: what we deliberately did not consider, and why.
verification_steps: how a human can independently audit each conclusion (citation, paragraph, page, line).
applicability_basis: the reasoning chain from your workflow to each requirement.
A PIF bundle without these fields is not a valid PIF bundle.
§ 11 · REGULATORY GUARDRAILS
For the function that signs the deployment.
RA and Quality teams set the rules; Preclari enforces them as a working surface, not as policy text.
Preclari does NOT opine on
Clinical trial protocol design
Pharmacovigilance case processing or adverse-event causality
Per-decision merits inside a high-risk AI system (Preclari addresses the system, not each inference)
These are real adjacent products. Preclari stays narrow on purpose.
Preclari DOES surface
Applicable requirements from a hand-curated corpus, with citation, page anchor, and retrieval date
Missing controls with criticality (required vs recommended)
Every assumption Preclari made, with impact-if-wrong
Clarifying questions that would change the output
Verification steps an independent auditor can run
v0.1 corpus is pharma GMP. Medtech (EU MDR + FDA) and the EU AI Act high-risk regime are in active onboarding. The Coverage page is the live, authoritative list — it is the source of truth and updates as the corpus grows.
Require specific control sets · your internal SOPs are added as additional missing-control checks alongside the public corpus.
Review every assumption before sign-off · the brief surfaces each assumptions_made entry; sign-off is per-assumption, not per-document.
Override applicability with captured reason · a reviewer can mark a requirement as out-of-scope for the engagement; the override and its reason persist in the audit log.
Deployment & data residency
Hosted MCP · Builder, Consultancy tiers. Preclari infrastructure in Switzerland and the EU.
Private MCP behind firewall · Team tier. Your tenant on Azure, AWS, or GCP. Preclari operates the runtime; corpus stays inside your boundary.
Air-gapped corpus snapshot · Private deployment. Signed snapshot shipped to on-prem; updates by signed delta.
Co-located reviewer surface · Brief renders to PDF or in your existing QMS via the PIF schema; no separate tool to learn.
For auditors Every MCP tool call is logged and replayable. Auditors can trace the agent's interaction with Preclari as part of the audit walk-through.
§ 12 · IMPACT
What changes when preflight becomes routine.
For the budget owner deciding whether Preclari earns its line item.
What changes for the team that ships AI workflows
Pilots that don't surprise the regulator. The first preflight surfaces what would have surfaced at QA review, weeks earlier.
QA findings caught while the workflow is still on paper. The cost shifts from rework and deviation reports to a paragraph edit.
Defensibility on demand. Every deployment ships with a portable PIF bundle a future inspector can read without Preclari installed.
Typical budget owner:
Head of Digital/AI, Head of Quality, or CIO. Procurement runs through whichever owns the AI workflow's deployment risk.
§ 13 · ACCESS
Access is currently by request.
Free access is curated, not self-serve. Approved users get a workspace, a monthly quota, and the full set of preflight tools. Builder, Consultancy, and Team tiers are for committed users; Private deployment is for regulated enterprise. Approval typically takes two business days.
Free · by request
50 sessions/month, full corpus, PIF export. For evaluators.
Builder
Independent practitioner. CHF 99/mo, 200 sessions, full PIF export.
Consultancy
Small consultancy. CHF 750/mo, 1,000 sessions, 10 premium credits, signed bundles.
Team
Internal team in a regulated industry. CHF 2,500/mo, 5,000 sessions, SSO, custom corpus.
Private deployment
Regulated enterprise. Customer cloud, pinned corpus snapshots, audit support.
For enterprise procurement: security, data-location, and audit documentation available under NDA.