What the FDA and EMA AI principles ask of your R workflow.

The short version

Most of the principles come down to one question a reviewer can ask of any AI-assisted analysis: what happened, who decided, and can you show it again? Software can help with some of that. It cannot do the thinking. Of the ten principles, two are well supported by existing open-source packages, five are partly supported, and three are about decisions and people that no package can make for you.

The tools named here are regulog, lineager and reproducr, R packages on CRAN. They produce records. Producing a record does not make a workflow validated or compliant, and the snippets are illustrations of the documented functions, not a validated procedure.

1. Human-centric by design Partial

What it asks. People stay in charge. Someone accountable looks at what the AI produced and decides what happens to it.

What you could show a reviewer. A named reviewer, the decision (accepted, edited, rejected), when it happened and what they were shown.

What the R tools give you. regulog records user-attributed actions, edits and signatures in a hash-chained log. Today the prompt and model output go into the log as hashes in an ordinary entry, with the text stored beside it. Capturing them natively is in development.

log <- regulog_init(app = "analysis", version = "1.0", user = "jsmith")
log_action(log,
  action = "review_accepted",
  object = "draft.R",
  reason = "AI draft checked against SAP section 6.1"
)
log_signature(log, "I reviewed the AI-drafted code and its output and accept it")

2. Risk-based approach Guidance only

What it asks. Validation and oversight scale with how the tool is used and how much could go wrong.

What you could show a reviewer. A short tiering rule: which outputs an AI may touch, how many reviewers each tier needs, and who decided.

What the R tools give you. No software does this for you. It is a decision for your quality group. The free evidence kit has a register to write it down, and the live demo shows one illustrative rule.

3. Adherence to standards Supported

What it asks. AI work sits inside the controls you already have for GxP records, including audit trails.

What you could show a reviewer. An audit trail you can verify independently of the system that wrote it.

What the R tools give you. regulog is designed around 21 CFR Part 11 and EU Annex 11: every entry is linked by a SHA-256 hash to the one before, so an inserted, deleted or edited entry shows up on verification, from the raw file and without the original R session. Using it does not make an organisation compliant. Which AI records fall under Part 11 is a decision for you and your QA group.

verify_log("logs/audit.rlog")
export_audit_trail(log, format = "csv", signed = TRUE, path = "audit_trail.csv")

4. Clear context of use Guidance only

What it asks. The task, scope and limits of each AI tool are written down.

What you could show a reviewer. One page per tool: tasks allowed, tasks excluded, data it may see, review level.

What the R tools give you. Writing it is the work, and it is process rather than code. The evidence kit includes a one-page template. A cheap habit that helps: record the context of use as the first entry of every run, so it is part of the chain.

log_note(log, paste(
  "Context of use: supportive analysis only.",
  "Excluded: primary analyses, any data modification."))

5. Multidisciplinary expertise Guidance only

What it asks. Statistics, QA, IT and regulatory people shape the use of the tool together.

What you could show a reviewer. Who from each function reviewed the set-up and agreed the controls.

What the R tools give you. This is about people, not packages. Training and joint review sessions help, which is why those sit on the services page rather than in the tooling.

6. Data governance and documentation Supported

What it asks. Data sources, handling and provenance are controlled and documented.

What you could show a reviewer. Which data version a run used, which rows were included or excluded, and why.

What the R tools give you. lineager traces rows from source to analysis dataset, records every exclusion with its reason and writes a provenance report styled after the CDISC Reviewer's Guide. regulog's rl_read() logs each data read as an entry.

adsl <- rl_read(log, haven::read_sas, "data/adsl.sas7bdat")
filter_log(log, action = "data_read")

7. Model design and development Partial

What it asks. Disciplined engineering: version control, testing and traceable changes.

What you could show a reviewer. The code and the environment it ran in, plus a record of every change between versions.

What the R tools give you. reproducr audits a script for the packages it calls, scores known breaking-change and seed risks, and certifies outputs with their environment metadata. regulog's log_change() records before and after values. This covers the R environment, not the training of a model.

report <- audit_script("final.R", renv = FALSE)
risk_score(report)
log_change(log, object = "draft.R", field = "code_sha256",
  before = old_hash, after = new_hash,
  reason = "Reviewer edit: rounding changed")

8. Risk-based performance assessment Partial

What it asks. Performance is judged against criteria that fit the use, and monitored for errors.

What you could show a reviewer. Predefined acceptance criteria, a comparison against them, and a record of what happened when something changed.

What the R tools give you. reproducr's certify() stores a baseline of outputs and check_drift() reports which ones changed. That detects change; it does not tell you whether an AI's answer is good. Model-specific metrics and thresholds are yours to define.

certify(list(coefs = coef(model)), tag = "baseline-v1")
check_drift(list(coefs = coef(model2)), against = "baseline-v1")

9. Lifecycle management Partial

What it asks. Updates, re-validation and monitoring after release, and retirement when appropriate.

What you could show a reviewer. Which state was validated, what changed since, and evidence of re-checking.

What the R tools give you. Certify a new tag for each validated state and use list_certs() and check_drift() to compare. The change-control process around it belongs to your quality system.

list_certs()
check_drift(current_outputs, against = "baseline-v1")

10. Clear, essential information Partial

What it asks. People who use or review the tool get plain information about its purpose, capabilities and limits.

What you could show a reviewer. A readable summary a reviewer can use without reading code.

What the R tools give you. repro_report() produces text, Markdown or HTML summaries in minimal, academic or pharma styles, and lineager writes structured provenance reports. Templates written for AI-specific documentation are still in development.

repro_report(report, risks, format = "text", style = "pharma")

What this adds up to

If you take only three actions from this note: write a one-page context of use for each AI tool, decide the review tier for each type of output, and make sure that every AI-assisted run leaves behind a log entry you can verify and a replay you can compare. The first two are documents. The third is where the packages earn their keep.

You can try an in-browser version of that trail without installing anything, start from the free evidence kit, or see the same table in the approach page.

Packages: regulog, lineager, reproducr. Function names in the snippets follow the packages' published reference manuals. Principle summary: IntuitionLabs (third-party).