# AI for Science > A living record of best practices for applying agentic AI to science. --- # For decision-makers Source: https://aiforscience.eu/for-decision-makers/index.md # For decision-makers Agentic AI puts software agents to work across the resources research runs on: databases, public endpoints, code, tools, and documents. The agents do the connecting and the routine assembly. The judgement, the provenance, and the accountability stay with people. This page is the short version of the [record](../best-practices/01-match-method-to-task.md) for the people who decide what to enable, resource, and require. Each point links to the practice it comes from.
Ask your own AI Assistant
ChatGPT Claude

Answers from the record's own text, citing each practice. No account, no install.

## What to enable - **A default that resources are open to agents.** Agents reach resources whether or not those were built for them. Planning for that access means agents can be steered to interfaces that work, instead of falling back to fragile ones. Set the default to open and decide the level of support per resource. See [BP02](../best-practices/02-default-to-agent-accessibility.md). - **More than one provider.** Keep more than one interface provider in use so the institution is not locked to a single vendor's agent ecosystem. See [BP03](../best-practices/03-register-and-vet-interfaces.md). ## What to resource - **Method choice and evaluation, not model spend.** An agent or a frontier model is one option among several, and often not the cheapest reliable one. Fund the work of choosing the method that fits the task and evaluating it. Total token spend is not a productivity metric. See [BP01](../best-practices/01-match-method-to-task.md). - **Core interfaces as infrastructure.** Fund maintained agent interfaces for the resources that are most used and most important, and tie the level of investment to demand and importance. This keeps resources open to agents without an open-ended maintenance bill. See [BP02](../best-practices/02-default-to-agent-accessibility.md). - **Documentation and data meaning as interface work.** Agents operate a tool or dataset from its documentation and metadata. Fund precise, current documentation and machine-readable data meaning. It is cheap to check, now load-bearing, and it helps the people who use the resource directly. See [BP05](../best-practices/05-documentation-and-data-for-agents.md). - **User research behind task-shaped interfaces.** Interfaces built around the tasks users actually perform cut load, cost, and error. Fund the work of learning those tasks. See [BP06](../best-practices/06-design-around-user-tasks.md). - **Shared benchmarks and independent evaluation.** Fund shared evaluation practice so adopters are not each testing blind, and support independent challenges on held-out data. See [BP08](../best-practices/08-evaluate-tools-before-trust.md). ## What to require - **Vetted, catalogued interfaces.** Agent interfaces (MCP servers, skills, plugins) should reach staff through a catalogue that reviews them and records who maintains each one and when it was last checked. Registration is where risk is assessed, and it doubles as an inventory of what is in use. See [BP03](../best-practices/03-register-and-vet-interfaces.md). - **Limits enforced by the system, with named owners.** A system that acts cannot be talked into following a rule; it can only be stopped from taking an action. The limits you care about belong in permission scopes and guardrails, not only in a policy document, and every agent responsibility needs a named human owner with clear stop, escalation, and shutdown paths. See [BP04](../best-practices/04-govern-autonomy-and-accountability.md). - **Evaluation before reliance.** A tool being popular, available, or convincing in a demo is not evidence that it is correct for your work. Require that tools feeding into results or decisions are tested on representative tasks first, in proportion to the stakes. See [BP08](../best-practices/08-evaluate-tools-before-trust.md). - **Traceable outputs.** Any answer an agent produces should be traceable to its sources, with the human and the agent contributions labelled. Provenance is what makes a result checkable, citable, and open to audit. See [BP07](../best-practices/07-provenance-and-citation.md). - **Stated human-in-the-loop levels.** Every use case should declare where human review is required and where the agent acts alone, and the system should enforce that level. Stronger checks apply where an action changes records, results, or the outside world. See [BP09](../best-practices/09-human-in-the-loop.md). - **Screening for serious-harm capabilities.** Some agent capabilities carry dual-use or high-consequence risk. Screen them before an agent is given reach, make screening mandatory where a mistake or misuse could cause serious harm, and refuse grant or service terms that would train third-party models on data held under withdrawable consent, because training cannot be undone. See [BP10](../best-practices/10-screen-dual-use-high-consequence.md). ## Where the risk is if you do nothing - **Agents route around missing interfaces.** Where a resource has no clean agent interface, agents fall back to legacy endpoints or scrape the service. This is fragile and adds load. (One observed instance is recorded in the [failures log](../best-practices/failures.md).) - **Policy that a system ignores.** The gap between written rules and enforced limits is the main risk as agents get more autonomous. Personal agents connected to staff mail, files, and calendars are part of the institution's risk even when no one deployed them centrally. See [BP04](../best-practices/04-govern-autonomy-and-accountability.md). - **Confident wrong answers.** Without a source trail, a wrong answer that looks right cannot be told from a correct one, and retracted work gets presented as current. See [BP07](../best-practices/07-provenance-and-citation.md). - **Harm that cannot be undone.** Misuse of a high-consequence capability, or training a third-party model on data whose consent can be withdrawn, cannot be walked back after the fact. The safeguard is to screen and contain before the action, not to review it afterwards. See [BP10](../best-practices/10-screen-dual-use-high-consequence.md). ## How to check it is working A short checklist. Each item links to the practice that defines it. - An inventory of the agents in use, including personal ones. ([BP04](../best-practices/04-govern-autonomy-and-accountability.md)) - Interfaces that record a maintainer and a review date. ([BP03](../best-practices/03-register-and-vet-interfaces.md)) - Permission scopes and guardrails enforced by the system, not only written down. ([BP04](../best-practices/04-govern-autonomy-and-accountability.md)) - A named owner for each agent responsibility, with escalation and shutdown paths. ([BP04](../best-practices/04-govern-autonomy-and-accountability.md)) - Evaluation evidence recorded before a tool is relied on. ([BP08](../best-practices/08-evaluate-tools-before-trust.md)) - A stated, enforced human-in-the-loop level for each use case. ([BP09](../best-practices/09-human-in-the-loop.md)) - Outputs that carry their sources, with human and agent contributions labelled. ([BP07](../best-practices/07-provenance-and-citation.md)) - Screening in place for any capability that could cause serious harm. ([BP10](../best-practices/10-screen-dual-use-high-consequence.md)) - Independent evaluation or audit where the stakes are high. ([BP04](../best-practices/04-govern-autonomy-and-accountability.md)) Governance here is ongoing, not a one-time policy. Guardrails are revised as agents and their uses change, and decisions are recorded. See [BP04](../best-practices/04-govern-autonomy-and-accountability.md). --- # Match the method to the task; do not default to an agent or a frontier LLM Source: https://aiforscience.eu/best-practices/01-match-method-to-task/index.md

Best practice 1

# Match the method to the task; do not default to an agent or a frontier LLM ## Practice
- First decide whether the task at hand requires an [agent](../glossary.md#agent). - Choose the method that fits the task; an agent or a frontier language model is one option among several. { #bp1-a1 } - Prefer scripts, pipelines, workflows, and smaller models (often cheaper, faster, more maintainable). { #bp1-a2 } - Agentic autonomy earns its cost when the task needs flexible, model-driven decisions at scale. { .afs-practice__pivot #bp1-a3 } - Add complexity only when a simpler approach falls short. - Where a specialized method works, using a frontier model introduces avoidable failure modes. { #bp1-a4 }
=== "For practitioners" Before reaching for an agent, ask whether a script, a fixed workflow, or an existing specialized model already does the job as well or better. Keep the frontier model for the open-ended, judgement-heavy steps where its flexibility is the point. A method that fits the task is usually cheapest to run and easiest to reproduce. === "For providers" Expose deterministic operations and specialized models as first-class tools. Incentivise the use of classical workflows where they are well established and functional. Do not assume every capability should be reached through a general model; the same demand-and-importance logic that governs where to invest in agent interfaces ([BP02](02-default-to-agent-accessibility.md)) applies to method choice. === "For governance" Fund method choice and evaluation, not model spend. "Total token spend" is not a useful productivity metric. The goal is the cheapest reliable method that meets the need; defaulting to frontier models raises cost and reproducibility risk without a matching gain. Support the evaluation that tells adopters when a simpler method suffices. ## Reasons An agent is a general instrument, and general instruments are rarely the most efficient way to do a fixed job. Vendor engineering guidance is explicit: start with the simplest approach, and add agentic complexity only when a task needs flexible, model-driven decisions at scale. Agents trade latency and cost for that flexibility. When real cost is measured, complex agents often fail to beat simple baselines. On well-specified tasks, a specialized or fine-tuned model can be more accurate than a larger general model, at a fraction of the cost. The reverse choice has a record of concrete harm in science: a frontier model asked to supply references fabricates a large share of them, and treating a model as a scientific instrument without method rigour produces over-optimistic results that do not reproduce. You cannot pick the right method without first understanding the task. Understanding the task includes understanding the net benefit expected from it. Controlled trials show forecast gains from agentic tools are frequently miscalibrated and vary by task and user, so state the expected benefit against a baseline with human oversight cost deducted, then measure the realised outcome against it. ## Examples - A team needs to extract one field from a fixed report format every week; a short parser does it deterministically, and the agent that was drafted for the job would have cost more and varied run to run. - A group classifying thousands of records fine-tunes a small model on labelled examples; it beats a zero-shot frontier model on their data and runs on their own hardware. - A literature step genuinely needs open-ended judgement across messy sources, so an agent is the right tool; the routine lookups it depends on are exposed as deterministic tools it calls rather than reasons about. - A scientist asks a chat model for supporting references and pastes them into a manuscript; several do not exist, a failure that a bibliographic search against a real index would not have produced. - A scientist uses a literature agent that is validated against a real index to autonomously find evidence for their opinion piece. The cited papers really exist, but on review, it becomes clear that the agent only read the abstracts of the papers, citing works for sentences they do not really support. The opinion piece is rejected. - A pipeline reports strong accuracy that collapses on re-run because the model was applied where the evaluation leaked; a simpler method with proper train/test separation would have been both honest and reproducible. - A group expects a large speedup from an agent and, before committing, writes down the expected net benefit against its current baseline with review and correction time subtracted; for its experienced users the projected gain is marginal, so it keeps the existing workflow and re-checks the estimate on a small pilot. ## Sources - [Anthropic, Building Effective AI Agents (2024)](../library/ref-anthropic-building-effective-agents-2024.md). Prefer the simplest solution; use workflows for well-defined tasks and agents only when flexibility is needed at scale; agents trade latency and cost for performance. Vendor-primary grounding. - [Kapoor et al., AI Agents That Matter (2024)](../library/ref-kapoor-agents-that-matter-2024.md). Under cost-controlled evaluation, state-of-the-art agents are needlessly complex and simple baselines can match them. - [Bucher & Martini, Fine-Tuned "Small" LLMs Still Outperform Zero-Shot Generative Models (2024)](../library/ref-bucher-fine-tuned-2024.md). A specialized smaller model can beat a general frontier model on a well-defined task. - [Kapoor & Narayanan, Leakage and the reproducibility crisis in ML-based science (2023)](../library/ref-kapoor-narayanan-leakage-2023.md). Misapplied models produce over-optimistic, non-reproducible results across many fields. - [Walters & Wilder, Fabrication and errors in ChatGPT citations (2023)](../library/ref-walters-wilder-2023.md). A concrete failure mode of using a frontier model where a retrieval method fits. - [JRC, The Role of AI in Scientific Research (2025)](../library/ref-jrc-ai-in-science-2025.md). AI framed as a tool in science, a chosen instrument rather than a default. - [EU Expert Forum on Frontier AI (2026)](../library/ec-expert-forum-2026.md). Domain-specific systems can outperform general-purpose models within their domains at far lower cost (§3.2.3), qualified by the report's caution that demand for smaller models is uncertain and that non-frontier access is an imperfect substitute for frontier access. - [MIT Project NANDA, The GenAI Divide (2025)](../library/mit-genai-divide-2025.md). Enterprise field evidence that task type, not model capability, decides fit: users prefer AI for simple work but humans by 9-to-1 for complex or long-term work (§4.3, pg. 13). Out-of-domain business report; cited as external context. - [Lobentanzer, Expectation–Realisation Gap for Agentic AI (2026)](../library/expectation-realisation-gap-2026.md). Review of controlled trials finding that forecast gains from agentic tools are miscalibrated and heterogeneous: constrained tasks sped up while expert high-context work was slowed, so method fit is decided per task and per user rather than by an average gain. Downweighted external context; the author is a contributor to this record. ## Change history - 2026-07-27: Added the Expectation–Realisation Gap review (Lobentanzer 2026) as downweighted context on heterogeneous, miscalibrated benefit, with a Reasons and Examples note that method choice includes stating and re-measuring expected net benefit with oversight cost deducted (bp1-a1, bp1-a3). - 2026-07-27: Added The GenAI Divide (MIT NANDA 2025) as a supporting source on task-based method fit (bp1-a1). - 2026-07-27: Created as BP01. Method-selection practice at the general end of the record; grounds the disciplined stance that an agent or frontier model is chosen, not assumed. Existing BP01 through BP09 renumbered to BP02 through BP10. --- # Default to agent-accessibility; prioritise effort by demand and importance Source: https://aiforscience.eu/best-practices/02-default-to-agent-accessibility/index.md

Best practice 2

# Default to agent-accessibility; prioritise effort by demand and importance ## Practice
- [Agents](../glossary.md#agent) use resources like humans do: databases, public endpoints, code, tools, and documents. { #bp2-a1 } - Often, programmatic use by agents cannot be distinguished from human users. { #bp2-a2 } - Resources should be [machine-actionable](../glossary.md#machine-actionable) and discoverable by default. { #bp2-a3 } - Access should be governed by resource. { #bp2-a4 } - However, not every resource needs its own maintained agent [interface](../glossary.md#interface). { .afs-practice__pivot #bp2-a5 } - How much effort to invest depends on how widely it is used and how important it is to the community. { #bp2-a6 } - Sorting resources into types based on usage and importance can help prioritise maintenance effort. { #bp2-a7 }
=== "For practitioners" The resources you use will support agents to different degrees, by design. If one you depend on is poorly supported, say so. Providers use demand to decide what to improve. === "For providers" Make resources machine-actionable and discoverable by default, then set the level of support by type. Sort resources by how widely used and important they are, and invest accordingly. Keep a generic path for minor resources instead of building a custom interface for each. Govern access (authenticate and rate-shape where needed); a default of accessibility does not mean unmetered access. === "For governance" Prioritisation is a funding decision. Back a scheme that ties interface investment to how used and important a resource is, and fund the top-tier interfaces as infrastructure. This keeps resources reachable by agents without an open-ended maintenance cost. ## Reasons Agents already reach resources whether or not they were built for them. Not planning for this does not stop it. It means agents use interfaces no one designed, with more load and worse results. Planning for it means agents can be steered to interfaces that work. Machine-actionability is not a new demand: it is the founding goal of the FAIR principles, which agents now make concrete. But a custom interface for every resource costs too much and is rarely worth it. Widely used and important resources are worth a proper interface. Minor resources can use a lighter, generic path. Sorting resources into types makes these choices clear. A default of accessibility is not a default of unlimited access. The Accessible principle (the *A* of *FAIR*) always allowed authentication. The load that automated clients now place on open resources makes governed access the realistic default. ## Examples - The maintainer of a heavily-used database ships a first-party MCP server covering the queries people actually run, and links it from the documentation. Traffic that used to arrive as thousands of small REST calls now comes through one path the provider designed, and answers improve because the agent is no longer reverse-engineering the API. - With no first-party interface on offer, a scientist reaches a popular resource through a third-party MCP server they have not checked. It maps one field to the wrong column, the analysis runs on the wrong data, and the output looks plausible while being wrong. A vetted first-party path is what would have avoided the detour (checking a third-party tool before trusting it is [BP08](08-evaluate-tools-before-trust.md); vetting at connect time is [BP03](03-register-and-vet-interfaces.md)). - A team spends weeks building and maintaining a bespoke agent interface for a niche tool that one group runs twice a year. The same effort spent on a top-tier resource would have served far more people; the work did not follow demand. - A minor tool stays reachable through a shared registry's metadata instead of a bespoke interface, so an agent can still discover and call it. A registry such as bio.tools (life sciences) is one worked instance of this light generic path. - A provider sorts its resources into tiers by how widely used and important they are, funds the top tier as maintained infrastructure, and leaves minor resources on the generic path. The ELIXIR Core Data Resources (life sciences) are one such tier, selected on quantitative and qualitative indicators. - A resource keeps a default-open path but authenticates and rate-shapes automated traffic, so a burst of agent calls does not knock it over for its human users. Its logs cannot tell agents from people, which is why the limit is set at the resource rather than inferred from the client. ## Sources - [ELIXIR TF Agentic AI: agenda and rolling best practice (2026)](../library/elixir-tf-agentic-ai-2026.md), Best Practice items 1 and 2. Provider stance and the resource typology. - [FAIR Guiding Principles (Wilkinson et al. 2016)](../library/ref-fair-2016.md). Grounds machine-actionability as the general goal; the Accessible principle permits authentication, so "accessible" never meant "open without limit". - [ELIXIR Core Data Resources (Drysdale et al. 2020)](../library/ref-elixir-cdr-2020.md). A concrete demand-and-importance typology with the top tier funded as infrastructure. Life-science instance, cited as an example. - [bio.tools registry (Ison et al. 2019)](../library/ref-biotools-2019.md). The light generic path for the long tail. Life-science instance, cited as an example. - [COAR survey on AI bots and crawlers (2025)](../library/ref-coar-ai-bots-2025.md). Evidence that open resources face heavy automated load and that blunt blocking also blocks real users. Qualifies "default accessible" toward governed access. ## Change history - 2026-07-27: Renumbered from BP01 to BP02 on inserting the new BP01 (match the method to the task). - 2026-07-27: Rewrote Examples as concrete scenarios (actor, action, outcome), including anti-patterns, replacing restatements of the practice; kept the labelled life-science instances (Core Data Resources, bio.tools). - 2026-07-26: Rewritten to be domain-neutral (FAIR as the general anchor; ELIXIR and bio.tools demoted to labelled examples) and to replace "open to agents" with machine-actionable, discoverable, and governed-per-tier, grounded in FAIR and the COAR load survey. - 2026-07-25: Created from the ELIXIR TF distillation (hooks 2, 3). --- # Register, vet, and manage agent interfaces through trusted channels Source: https://aiforscience.eu/best-practices/03-register-and-vet-interfaces/index.md

Best practice 3

# Register, vet, and manage agent interfaces through trusted channels ## Practice
- An [agent](../glossary.md#agent) reaches tools, data, and actions outside the model through [interfaces](../glossary.md#interface) (e.g., [MCP](../glossary.md#mcp) servers, skills, plugins). { #bp3-a1 } - Each interface runs code and acts for the user, so each is a point where risk enters. { #bp3-a2 } - Interfaces should be published through a channel that lists and vets them. { #bp3-a3 } - Listing makes an interface discoverable and records where it comes from and who maintains it. { #bp3-a4 } - Vetting is a separate step; a discoverable interface is not automatically safe. { .afs-practice__pivot #bp3-a5 } - Public interfaces (e.g., public GitHub repositories) are generally vulnerable to [prompt injection](../glossary.md#prompt-injection) attacks. { #bp3-a6 } - Safety and omnipotence are on a tradeoff; a system that can run arbitrary code (e.g., from web search) is vulnerable to injection – a system that cannot is less autonomous. { #bp3-a7 }
=== "For practitioners" Prefer interfaces that have been vetted, not just listed. Before trusting one with your data or actions, check who maintains it, when it was reviewed, and what it is allowed to do. Presence in a registry is not a safety check on its own: an unvetted interface can carry prompt-injection or malware risk you cannot see from its description. === "For providers" List your interfaces through a channel that records their source and maintainer, and have them vetted (reviewed or signed) before they are trusted. Route agent traffic through an approved, identified channel so you can shape and rate-limit it by identity, which beats blocking addresses that also blocks real users. If you adapt or repurpose someone else's interface, you may take on the duties of its provider. === "For governance" Treat listing and vetting as two things: an inventory and a safety check. Back a trusted channel, require listed interfaces to record their source and review date, and make vetting (not mere registration) the point where risk is assessed. Keep more than one provider in use so the institution is not locked to a single vendor. ## Reasons An agent interface runs code and acts for the user. A malicious or careless one can carry malware or prompt-injection attacks hidden in a tool description, which the model reads but the user does not see. Prompt injection is the top-ranked risk in the OWASP Top 10 for LLM Applications, and tool poisoning is a documented attack on agent interfaces specifically. This is why listing and vetting are different acts. A registry that only lists (like the official MCP Registry, which records self-reported data and runs no security review) makes interfaces discoverable but guarantees nothing about safety. Vetting, a review or a signed provenance record, is what lets a user trust an interface. The same approved channel also makes traffic manageable: identified agent traffic can be shaped and rate-limited per identity, whereas blocking addresses also blocks real users, and modern bots rotate addresses anyway. Knowing where an interface comes from, and keeping more than one option open, avoids lock-in to a single provider. ## Examples - A lab installs an MCP server because a public registry lists it and it has many stars, treating the listing as a safety check. The tool description carries instructions the model reads but the user never sees, and the agent leaks data on first use; nothing in the listing had vetted it. - A provider publishes its interface through a channel that records source, maintainer, and review date and signs it, so a user can see it was reviewed before trusting it with their data or actions. - An agent with web search and code execution reads a public repository issue that contains injected instructions and runs them; a colleague's agent, limited to a fixed set of read-only tools, is unaffected but can do less. The reach that makes an agent useful is the same reach that exposes it, so the safeguard has to match the capability. - A resource routes agent calls through an approved, identified channel and rate-limits per identity, instead of blocking address ranges that also lock out real users. It declares what automated clients may do in machine-readable form; the emerging IETF AIPREF vocabulary is one instance. - A group fine-tunes and repackages someone else's interface and ships it under their own name, without realising that under the EU AI Act a substantial modification can move the provider's duties onto them (the threshold is defined for high-risk systems and its exact bounds are still being clarified). - An institution keeps more than one agent ecosystem in use, so a critical resource is not reachable only through a single vendor's channel. - When the approved list is too narrow to do real work, people route around it: in one enterprise survey 40% of organisations bought an official tool while staff at over 90% used personal AI tools unofficially, often to better effect. A vetting process that watches what people actually reach for, and brings the useful cases into the trusted channel, holds up better than one that only blocks. ## Sources - [ELIXIR TF Agentic AI: agenda and rolling best practice (2026)](../library/elixir-tf-agentic-ai-2026.md), Best Practice items 8 and 9 (registration implies review; managing agent traffic through an approved channel). - [Agentic AI in the higher-education system (2026)](../library/hfd-agentic-ai-hochschulsystem-2026.md), §5.2 to 5.3 (deployer-versus-provider, infrastructure as a governance point). - [EU Expert Forum on Frontier AI (2026)](../library/ec-expert-forum-2026.md), §4.2.2 (provider diversity and openness). Consistent with, grounding only. - [OWASP Top 10 for LLM Applications 2025](../library/ref-owasp-llm-top10-2025.md) and [OWASP MCP Top 10](../library/ref-owasp-mcp-top10.md). Prompt injection (LLM01) and tool poisoning (MCP03) as the documented risks vetting guards against. - [Invariant Labs, tool poisoning attacks (2025)](../library/ref-invariant-tool-poisoning-2025.md). How a poisoned tool description hides instructions from the user. - [Official MCP Registry (2025)](../library/ref-mcp-registry-2025.md). Evidence that the official registry lists self-reported data and does not vet, so listing and vetting must be kept distinct. - [EU AI Act, Article 25](../library/ref-eu-ai-act.md). Substantial modification can move provider responsibility to whoever changed the system. - [IETF AIPREF vocabulary (draft)](../library/ref-ietf-aipref.md). Emerging machine-readable way to declare access preferences to automated clients. - [MIT Project NANDA, The GenAI Divide (2025)](../library/mit-genai-divide-2025.md). Enterprise field evidence of a "shadow AI economy": unsanctioned personal-tool use outpaces governed deployment and often delivers better results (§3.3, pg. 8), so vetting should learn from observed usage rather than only restrict it. Out-of-domain business report; qualifies rather than grounds the practice. ## Change history - 2026-07-27: Added a "what it looks like in practice" example on shadow usage and vetting that learns from observed use, grounded in The GenAI Divide (MIT NANDA 2025) as a qualifier (bp3-a3). - 2026-07-27: Renumbered from BP02 to BP03 on inserting the new BP01 (match the method to the task). - 2026-07-27: Rewrote Examples as concrete scenarios (actor, action, outcome), including anti-patterns; kept the labelled instances (IETF AIPREF, EU AI Act Article 25) and cross-references. - 2026-07-26: Rewritten to separate listing from vetting (the official MCP Registry lists but does not vet), merge agent-traffic management into this practice, reframe traffic control around identified traffic rather than IP blocking, qualify the Article 25 point, and add OWASP, MITRE-adjacent, and AIPREF grounding. - 2026-07-25: Created from the ELIXIR TF distillation (hooks 9, 10), grounded in the HFD paper and the EU Expert Forum entry. --- # Govern agent autonomy and accountability Source: https://aiforscience.eu/best-practices/04-govern-autonomy-and-accountability/index.md

Best practice 4

# Govern agent autonomy and accountability ## Practice
- An [agent's](../glossary.md#agent) limits ([guardrails](../glossary.md#guardrails)) belong in the system that runs it, not only in written policy. { #bp4-a1 } - An agent cannot be talked into following a rule; it can only be stopped from taking an action. { #bp4-a2 } - Limits have to be implemented in permission scopes, autonomy limits, and shutdown paths. { #bp4-a3 } - Regardless of implemented safeguards, something can always go wrong. { .afs-practice__pivot #bp4-a4 } - Thus, every agent also needs a named human owner for each responsibility it carries. { #bp4-a5 } - The agent's actions have to be logged under an attributable identity, so that accountability can be traced after the fact. { #bp4-a6 }
=== "For practitioners" When you run an agent in your own work, set its limits where they take effect: what it can access, how far it can act on its own, and when it must stop and ask. Stay the decision-maker for anything that affects results or other people. A personal agent connected to your mail and files is part of the institution's risk, even if no one else set it up. === "For providers" Put the limits you promise in the system, not only in the docs, so an agent cannot exceed its scope by being told to. Give operators the stop, escalation, and shutdown controls they need, log agent actions under attributable identities, and record which role holds each responsibility. Roll out new agent features in stages, with clear success and go-live criteria. === "For governance" Written policy alone does not bind a system that acts. Move the rules you care about into guardrails and enforced permissions. Give each responsibility a named role with clear escalation and shutdown paths, keep a list of the agents in use, require that their actions are logged and attributable, and require independent evaluation where the risk is high. Decide what autonomy the organisation is willing to grant, and treat governance as ongoing, not a one-time policy. ## Reasons An agent acts. A policy document tells a person what to do. It does nothing to a system that only follows the actions it is allowed to take. As agents get more autonomous, the gap between written rules and enforced limits becomes the main risk. To close it, put the limits where they take effect: what the agent can access, how far it can act without a human, and when it must stop or escalate. Accountability has to be just as concrete. If responsibility sits with "the institution" in general, no one is answerable; it has to sit with named roles, with clear paths to escalate and to shut an agent down. Accountability also needs a record: if an agent's actions are not logged under an attributable identity, no one can reconstruct what it did or hold the right role answerable. Personal agents with broad access to mail, files, and calendars sit outside all of this, so governance has to cover individual use, not only institutional deployments. This is the consensus position across the main governance frameworks (NIST, the EU AI Act, OECD, ISO/IEC 42001), which agree on enforced limits, named accountability, an agent inventory, logging, and independent review. ## Examples - A policy document says the agent must not delete production records, but nothing in the system stops it; a [prompt-injected](../glossary.md#prompt-injection) instruction gets it to do exactly that. The rule was written, not enforced. - The same agent runs with a scoped token that carries no delete permission and a shutdown control a named on-call engineer can trigger, so the injected instruction fails because the action was never available to it. - After an agent writes a wrong value to a shared dataset, the team traces it through the action ledger to the run, the model version, and the role that owned that workflow, and closes the gap. - Responsibility for an agent sits with "the department" in general; when it misbehaves, no one is answerable and no one has clear authority to shut it down. - A new agent feature goes live for low-risk cases first, with success and go-live criteria and an accepted risk limit set in advance, before any wider rollout. - A personal agent connected to a researcher's mail and files is entered in the institution's agent inventory and reviewed like any deployed one, because its broad access is part of the same risk. ## Sources - [Agentic AI in the higher-education system (2026)](../library/hfd-agentic-ai-hochschulsystem-2026.md), §4 to 6. The "from guidelines to guardrails" framing is quoted at §5.2. That quotation is attributed in the source paper to "Kassorla et al. (2026)", a reference we could not verify as a published work; the underlying point is independently supported by the frameworks below, which is what this practice relies on. - [EU Expert Forum on Frontier AI (2026)](../library/ec-expert-forum-2026.md), §4.2.3 (independent audit, evaluation and verification capacity). Consistent with, grounding only. - [NIST AI RMF and Generative AI Profile](../library/ref-nist-ai-rmf.md). GOVERN roles and accountability, a documented system inventory, and stop-build authority. - [EU AI Act, Articles 14 and 26](../library/ref-eu-ai-act.md). Named natural persons for oversight and deployer duties. - [EU AI Omnibus (2026)](../library/ai-omnibus-2026.md), Art 5(1a)(a)(ii). A provider is responsible where a prohibited output is a reasonably foreseeable and reproducible outcome absent adequate technical safeguards, which places the limit in the system rather than in policy (bp4-a1). - [OECD AI Principles (2024 update)](../library/ref-oecd-ai-principles-2024.md). Traceability placed under Accountability. - [ISO/IEC 42001:2023](../library/ref-iso-42001-2023.md). Assigned accountability, an AI system inventory, and governance as continual improvement. - [OpenAI, Practices for Governing Agentic AI Systems (2023)](../library/ref-openai-governing-agentic-ai-2023.md). Constraining the action space, human accountability, and an action ledger. - [Chan et al., Visibility into AI Agents (FAccT 2024)](../library/ref-chan-visibility-2024.md). Agent identifiers, real-time monitoring, and activity logging as the substrate of accountability. - [Kolt, Governing AI Agents (2025)](../library/ref-kolt-governing-agents-2025.md). Legal treatment of agent accountability and control. - [European Commission JRC, The Role of AI in Scientific Research (JRC143482, 2025)](../library/ref-jrc-ai-in-science-2025.md). AI as a tool with human accountability in science. The HFD source attributes a "situated judgement is not automatable" claim to the JRC; we cite the JRC report for the accountability framing and do not attribute that exact wording to it without a located passage. ## Change history - 2026-07-27: Added the EU AI Omnibus (2026) as a supporting source on bp4-a1 (technical safeguards in the system, not policy; Art 5(1a) foreseeable-misuse standard). - 2026-07-27: Renumbered from BP03 to BP04 on inserting the new BP01 (match the method to the task). - 2026-07-27: Rewrote Examples as concrete scenarios (actor, action, outcome), including anti-patterns, replacing restatements of the practice. - 2026-07-26: Rewritten to merge action-logging and attributable agent identity into the practice, add independent grounding (NIST, EU AI Act, OECD, ISO/IEC 42001, OpenAI, Chan et al., Kolt), and add two citation caveats: the "guidelines to guardrails / Kassorla et al." attribution in the source could not be verified, and the JRC "not automatable" wording is unconfirmed. - 2026-07-25: Created from the HFD distillation, grounded in the EU Expert Forum entry. New practice added because the guidelines-to-guardrails point is a separate action, not a sub-case of stating a human-in-the-loop level ([BP09](09-human-in-the-loop.md)). --- # Write documentation and data for agents Source: https://aiforscience.eu/best-practices/05-documentation-and-data-for-agents/index.md

Best practice 5

# Write documentation and data for agents ## Practice
- Documentation, data, and metadata are now an [interface](../glossary.md#interface). { #bp5-a1 } - An [agent](../glossary.md#agent) operates a tool or dataset from its tool description / metadata, docstrings, and docs. { #bp5-a2 } - User- and agent-facing documentation needs to be precise, current, and published in context with meaning and examples. { #bp5-a3 } - Precise documentation helps human users and agents alike. { #bp5-a4 }
=== "For practitioners" Write your code and notebooks as if an agent will re-run them; assume that one will. Put units, data versions, and assumptions in the docstring or close to the code. When a resource's documentation misleads your agent, raise the issue with the provider. === "For providers" Treat docs, docstrings, tool descriptions, and metadata as an interface. Run examples and test them in CI so they cannot drift (e.g., using `doctest`). Publish data with schemas, controlled vocabularies, and machine-readable metadata, and give examples of how to query it. === "For governance" Machine-readable documentation is cheap to check and more important than ever. Include it in resource review, and fund documentation and data meaning as essential interface work. Reward it when assessing any resource. ## Reasons Agents read documentation literally. What a human works out from context can send an agent the wrong way, and an out-of-date example can lead to silent failure, if it results in a plausible but wrong result. Data without stated meaning makes the agent guess at meaning and units. The FAIR principles aim at making data findable, accessible, interoperable, and reusable; this now applies to agents. A research agent that tracks a field is only as good as the metadata, citations, and retraction signals it can read. This work also benefits the people who use the resource directly, and current and future maintainers of the resource. ## Examples - A parameter is renamed but its docstring still shows the old name; a human reader infers the new one from context, while the agent calls it verbatim, the run fails, and a plausible but wrong number comes back. - Examples in the documentation run as doctests in CI, so when the API changes a broken example fails the build and is fixed before it can mislead a human or an agent. - A tool description gives only prose, with no parameter types, units, or valid ranges; the agent passes an out-of-range value and cannot interpret the error it gets back. - A dataset is published with its meaning attached: a schema, controlled vocabularies, and machine-readable metadata including provenance and, where relevant, retraction status, so the agent does not have to guess at units or fields. General-purpose formats such as W3C DCAT, Croissant, datasheets, and model cards carry this; domain profiles such as Bioschemas (life sciences) are concrete instances of the same idea. - A resource ships natural-language-to-query examples, for a query language such as SPARQL or Cypher, so an agent can turn a user's question into a correct query. - The same documentation is offered in a form an agent can read directly (plain text, markdown, structured metadata), not only as a rendered web page. A convention like `llms.txt` is one proposed approach, not yet a ratified standard. ## Sources - [ELIXIR TF Agentic AI: agenda and rolling best practice (2026)](../library/elixir-tf-agentic-ai-2026.md), Best Practice items 3 and 5. - [Agentic AI in the higher-education system (2026)](../library/hfd-agentic-ai-hochschulsystem-2026.md), §3.3 (research-agent source requirements). Consistent with, grounding only. - [FAIR Guiding Principles (Wilkinson et al. 2016)](../library/ref-fair-2016.md). Machine-actionability as the founding motivation; agents make it concrete. - [W3C DCAT v3 (2024)](../library/ref-dcat3-2024.md), [Croissant (MLCommons 2024)](../library/ref-croissant-2024.md), [Datasheets for Datasets (Gebru et al. 2021)](../library/ref-datasheets-2021.md), and [Model Cards (Mitchell et al. 2019)](../library/ref-model-cards-2019.md). Domain-neutral standards for machine-readable data and model documentation. ## Change history - 2026-07-27: Renumbered from BP04 to BP05 on inserting the new BP01 (match the method to the task). - 2026-07-27: Rewrote Examples as concrete scenarios (actor, action, outcome), including anti-patterns; kept the labelled instances (DCAT, Croissant, datasheets, model cards, Bioschemas, llms.txt). - 2026-07-26: Rewritten to be domain-neutral (FAIR, DCAT, Croissant, datasheets, and model cards as the general anchors; Bioschemas and SPARQL/Cypher demoted to labelled examples), to add tool descriptions alongside datasets, and to flag `llms.txt` as a proposed convention rather than a standard. - 2026-07-25: Created from the ELIXIR TF distillation (hooks 4, 6), grounded in the HFD paper. Replaces the dummy BP0 on documentation and adds the data-and-examples dimension. --- # Design agent interfaces around user tasks, not raw endpoints Source: https://aiforscience.eu/best-practices/06-design-around-user-tasks/index.md

Best practice 6

# Design agent interfaces around user tasks, not raw endpoints ## Practice
- An agent [interface](../glossary.md#interface) works best when it is built around the tasks a user wants to complete. { #bp6-a1 } - Simply passing on pre-existing endpoints ("wrapping") is fast but often does not respect agent patterns. { #bp6-a2 } - Wrapping an API one call at a time forces the [agent](../glossary.md#agent) to assemble each task itself, which is slow, costly, and error-prone. { #bp6-a3 }
=== "For practitioners" If a routine task takes many awkward steps, report it. Providers shape interfaces around real use from this kind of feedback, and your cases are the evidence they need. === "For providers" Start from the tasks users do, not the endpoints you already have. Shape operations so a common goal takes as few calls as possible, and watch for ones that trigger many small calls. Learn what your users want; it may be different from your assumptions. === "For governance" Interfaces built around user tasks cut load and cost, and work more reliably. Governance is barely involved directly, but it is worth supporting and funding the user research that makes this possible. ## Reasons An API for programmers exposes small operations that a developer combines by hand. An agent given the same operations has to work out how to combine them for every task. That means many small calls, more server load and cost, and more chances to go wrong. Vendor engineering guidance reports the same failure mode: tools that merely wrap existing endpoints perform worse than a few tools built for high-impact workflows, and a large, fine-grained tool surface measurably raises token cost and lowers the agent's accuracy at picking the right call. An interface built around real tasks (the questions users ask, the analyses they run) lets the agent reach the goal in a few calls. There is more than one way to get there: shaping task-level tools is one, and for very large APIs, letting the agent write code against the endpoints (progressive disclosure, code execution) is another. Both need to know what users are trying to do, and providers often do not, so learning the real use cases is part of the job. ## Examples - A provider exposes its API one endpoint per tool; to answer one common question the agent makes dozens of small calls, hits rate limits, and stitches the pieces together wrong. - The provider replaces those with a single operation shaped around the question users actually ask, and the same task now takes one call. - Watching real usage, a provider finds users mostly want a comparison the API never offered directly, adds a task-level tool for it, and drops an assumption about what people wanted that turned out to be wrong. - A spike of many tiny calls aimed at one goal flags an interface that is misaligned with how it is used, and prompts a redesign. - For a very large API, instead of hand-building a task tool for every workflow, the provider lets the agent write code against the endpoints (progressive disclosure and code execution). ## Sources - [ELIXIR TF Agentic AI: agenda and rolling best practice (2026)](../library/elixir-tf-agentic-ai-2026.md), Best Practice item 4, and the July 2026 discussion on providers' limited view of their users. - [Anthropic, Writing effective tools for agents (2025)](../library/ref-anthropic-writing-tools-2025.md). Wrapping existing endpoints is a common error; build a few tools for high-impact workflows. Vendor-primary grounding for this practice. - [Anthropic, Code execution with MCP (2025)](../library/ref-anthropic-code-execution-mcp-2025.md) and [Advanced tool use (2025)](../library/ref-anthropic-advanced-tool-use-2025.md). Quantify the token cost of per-endpoint tool use and the accuracy loss from a large tool surface; document progressive disclosure as the alternative remedy. - [Model Context Protocol specification](../library/ref-mcp-spec.md). The interface substrate the practice is about. - [MIT Project NANDA, The GenAI Divide (2025)](../library/mit-genai-divide-2025.md). Enterprise field evidence that tools fail on workflow fit rather than model quality: custom systems stall due to "brittle workflows ... and misalignment with day-to-day operations", and buyers want a "deep understanding of our workflow" (pg. 3, pg. 15). Out-of-domain business report; cited as external context. ## Change history - 2026-07-27: Added The GenAI Divide (MIT NANDA 2025) as a supporting source on workflow fit (bp6-a1). - 2026-07-27: Renumbered from BP05 to BP06 on inserting the new BP01 (match the method to the task). - 2026-07-27: Rewrote Examples as concrete scenarios (actor, action, outcome), including an anti-pattern, replacing restatements of the practice. - 2026-07-26: Rewritten to add vendor-primary grounding (the Anthropic tool-design guidance, with quantified evidence) and to note the two accepted remedies to endpoint-wrapping (task-level tools and code execution for very large APIs). "Providers don't know their users" kept as stated judgement. - 2026-07-25: Created from the ELIXIR TF distillation (hooks 5, 12). --- # Make provenance and citation first-class Source: https://aiforscience.eu/best-practices/07-provenance-and-citation/index.md

Best practice 7

# Make provenance and citation first-class ## Practice
- Any answer an [agent](../glossary.md#agent) gives should be traceable to its sources and open to audit. { #bp7-a1 } - It should be clear what was done by a human and what by an agent. { #bp7-a2 }
=== "For practitioners" Treat an agent answer with no source trail as unchecked. Keep the link between a result and its evidence, and mark what the agent produced and what you did, so the work can be checked and cited later. Disclose agent use where it matters (in a paper, a report, a review). You are still accountable for the judgement, whatever the agent found. === "For providers" Make provenance part of the output, not an add-on. Return sources with each answer, detailed enough to verify, pass through citation and retraction status, and mark agent-generated content. Record enough of each run (model version, inputs, tool calls) that it can be re-examined. Machine-readable provenance is what lets others evaluate and audit your system. === "For governance" Provenance comes before audit and trust. Require that agent outputs be traceable, that human and agent contributions be clearly separated, and that agent use be disclosed where results are published. Use that trace as the basis for independent evaluation where the stakes are high. ## Reasons Science depends on the path back to evidence: results are trusted because they can be checked. Without a path back to the sources, a claim cannot be checked, cited, or corrected, and a wrong answer that looks right cannot be told apart from a correct one. This is not hypothetical: studies find large fractions of LLM-produced citations are fabricated or wrong, and AI research tools have been shown to cite retracted papers without flagging them. It also matters to separate what a human did from what the agent produced, for authorship, accountability, and tracing errors. There is wide editorial consensus (ICMJE, COPE) that AI cannot be an author and that its use must be disclosed. A research agent has to pass citation and retraction status through to its output, or it will present withdrawn work as current. ## Examples - An agent returns a confident literature summary with no sources; a reader cannot tell a sound claim from a fabricated one, and later finds that one cited paper does not exist. - Each answer instead carries references detailed enough to check the specific claim, and cited work passes through retraction status, so a withdrawn study is flagged rather than presented as current. The NISO CREC recommended practice and the open Crossref/Retraction Watch data make this checkable. - An agent-written passage is pasted into a manuscript with no marking; a co-author cannot tell which text and which analysis were the agent's, and authorship and error-tracing get muddled. - Human and agent contributions are labelled, in outputs and in anything the agent writes to, agent use is disclosed where the work is published, and the trace is machine-readable (for example W3C PROV, RO-Crate, or CRediT) so it can be checked automatically. - The run is recorded: model version, inputs, and tool calls kept so a surprising result can be re-examined and, where possible, re-run. - The agent supplies the traceable evidence and the person makes the call, remaining accountable for the judgement. ## Sources - [ELIXIR TF Agentic AI: agenda and rolling best practice (2026)](../library/elixir-tf-agentic-ai-2026.md), Best Practice item 6. - [Agentic AI in the higher-education system (2026)](../library/hfd-agentic-ai-hochschulsystem-2026.md), §3.3 (source traceability, retraction notices) and §4.1 (situated judgement is not automatable). Consistent with, grounding only. - [EU Expert Forum on Frontier AI (2026)](../library/ec-expert-forum-2026.md), §4.2.3 (evaluation and verification rest on traceability). Consistent with, grounding only. - [W3C PROV-O (2013)](../library/ref-prov-o-2013.md) and [CRediT (ANSI/NISO Z39.104-2022)](../library/ref-credit-2022.md). Machine-readable provenance and contribution attribution. - [ICMJE / COPE on AI and authorship (2023)](../library/ref-icmje-cope-2023.md). AI cannot be an author; use must be disclosed; humans remain accountable. - [NISO CREC RP-45-2024](../library/ref-niso-crec-2024.md) and [Crossref / Retraction Watch](../library/ref-crossref-retraction-watch-2023.md). The standard and the open data for propagating retraction status. ## Change history - 2026-07-27: Renumbered from BP06 to BP07 on inserting the new BP01 (match the method to the task). - 2026-07-27: Rewrote Examples as concrete scenarios (actor, action, outcome), including anti-patterns; kept the labelled instances (NISO CREC, Crossref/Retraction Watch, PROV, RO-Crate, CRediT). - 2026-07-26: Rewritten to add standards grounding (PROV-O, CRediT, ICMJE/COPE, NISO CREC, Crossref/Retraction Watch), fold in run-level recording (reproducibility) and disclosure of agent use, and cite the fabricated-citation and cite-retracted-work evidence as support. - 2026-07-25: Created from the ELIXIR TF distillation (hook 7), grounded in the HFD paper and the EU Expert Forum entry. --- # Evaluate / benchmark agentic tools before trusting their outputs Source: https://aiforscience.eu/best-practices/08-evaluate-tools-before-trust/index.md

Best practice 8

# Evaluate / benchmark agentic tools before trusting their outputs ## Practice
- Run task-specific benchmarks before giving an [agent](../glossary.md#agent) autonomy in your workflow. { #bp8-a1 } - Before an AI system informs scientific work, it needs to prove its suitability for the task at hand. { #bp8-a2 } - For LLM-driven systems, there is no good general proxy (e.g., leaderboards) for their correctness in individual applications. { #bp8-a3 } - Benchmarking is separate from safety ([BP03](03-register-and-vet-interfaces.md)) and auditability ([BP07](07-provenance-and-citation.md)). { .afs-practice__pivot #bp8-a4 } - It is the adopter measuring a tool's performance on representative tasks and recording how it fails. { #bp8-a5 }
=== "For practitioners" A tool being available, popular, or well-described is not evidence that it is correct for your task. Before you rely on its output, run it on cases where you know the answer, check it across repeated runs, and note where it breaks. Keep that evidence; it is what justifies trusting the result. === "For providers" Publish evaluation evidence for what you ship: how the tool was tested, on what tasks, with what error rate and known failure modes. Make it easy for adopters to reproduce your evaluation. Benchmark scores on general tasks do not tell a user whether the tool is reliable for theirs. === "For governance" Require evaluation before reliance for tools that feed into results or decisions, proportionate to the stakes. Fund shared benchmarks and evaluation practice so adopters are not each testing blind. Support and fund independent evaluation efforts and community-driven challenges on held-out data. ## Reasons Whether a tool is safe to connect and whether it is correct are different questions, answered by different people. Registration and vetting ([BP03](03-register-and-vet-interfaces.md)) concern security at connect time; provenance and auditability ([BP07](07-provenance-and-citation.md)) concern the ability to trace answers after execution. Evaluation (this practice) concerns accuracy and reliability at use time. Goodhart's law states that a metric that becomes the target ceases to be a good metric; LLM leaderboards today decide on highest-volume investments for frontier AI companies. Evaluation is the task of users, adopters, and community; only they know the task *and* possess the necessary stakes and incentives to desire an objective evaluation. The evidence is clear that this cannot be skipped: a single benchmark score does not predict deployment reliability, agents vary run to run, and [confabulation](../glossary.md#confabulation) is common. A tool that looks capable in a demo can be wrong in ways that only representative testing reveals. ## Examples - A team adopts a tool because it tops a public leaderboard, then finds it wrong on their own data; the leaderboard measured a different task from theirs. - Before relying on a tool, the adopter runs it on cases where the answer is known, checks it across repeated runs, and records where it breaks; that evidence is what justifies trusting the result. - A tool that looked convincing in a demo is wired into a study without testing, and a confabulated value reaches an analysis before anyone checks it. - A provider ships evaluation evidence with the tool (tasks, metrics, error rate, known failure modes) that an adopter can reproduce, not only a feature description. - Red-teaming and hallucination/confabulation testing are run as the safety-and-correctness side of the same evaluation, not a separate afterthought. - Evaluations follow an established checklist (for example REFORMS for ML-based science, or a reproducibility checklist), so different groups' results are comparable. ## Sources - [ELIXIR TF Agentic AI: agenda and rolling best practice (2026)](../library/elixir-tf-agentic-ai-2026.md), Cautions and gaps: how to assess whether a skill or MCP server is useful and safe is recorded there as an open question and a candidate future practice. - [REFORMS reporting standards (Science Advances 2024)](../library/ref-reforms-2024.md). Consensus reporting standards for machine-learning-based science. - [NeurIPS Paper Checklist](../library/ref-neurips-checklist.md). Reproducibility and evaluation reporting practice. - [MIT Project NANDA, The GenAI Divide (2025)](../library/mit-genai-divide-2025.md). Enterprise field evidence that buyers who "benchmark tools on operational outcomes, not model benchmarks" succeed far more often; general benchmark scores do not predict fitness for a specific task (§6.2, pg. 20). Out-of-domain business report; cited as external context. - [EU AI Omnibus (2026)](../library/ai-omnibus-2026.md), Art 4a. The amended AI Act sets a conditional legal basis for processing special-category data to detect and correct bias, an evaluation dimension, subject to strict safeguards (bp8-a2). ## Change history - 2026-07-27: Added the EU AI Omnibus (2026) as a qualifying source on bp8-a2 (conditional legal basis for special-category data in bias detection; Art 4a). - 2026-07-27: Added The GenAI Divide (MIT NANDA 2025) as a supporting source on outcome-based evaluation over benchmark scores (bp8-a3). - 2026-07-27: Renumbered from BP07 to BP08 on inserting the new BP01 (match the method to the task). - 2026-07-27: Rewrote Examples as concrete scenarios (actor, action, outcome), including anti-patterns; kept the labelled instance (REFORMS). - 2026-07-26: Created. New practice for adopter-side evaluation of agentic tools, distinct from vetting at registration ([BP03](03-register-and-vet-interfaces.md)) and from self-audit of one's own agent ([BP04](04-govern-autonomy-and-accountability.md)). The ELIXIR task force flagged evaluation as an unresolved open question; red-teaming and hallucination-rate testing fold in as its safety and correctness dimensions. --- # State human-in-the-loop requirements explicitly Source: https://aiforscience.eu/best-practices/09-human-in-the-loop/index.md

Best practice 9

# State human-in-the-loop requirements explicitly ## Practice
- Every [agent](../glossary.md#agent) use case should state its [human-in-the-loop](../glossary.md#hitl) (HITL) level plainly. { #bp9-a1 } - HITL involvement can be mandatory or optional; it can range between tight in-process control and a mere final check. { #bp9-a2 } - A workflow stating no HITL involvement means it has full autonomy. { #bp9-a3 } - Left unstated, no one knows where a person is required and where the agent acts alone. { #bp9-a4 } - Stating the level is necessary, but not sufficient: the check has to be designed so it actually works in deployment. { .afs-practice__pivot #bp9-a5 } - HITL engagement provenance should be recorded according to [BP07](07-provenance-and-citation.md). { #bp9-a6 }
=== "For practitioners" Know the HITL level of the agent workflows you use, and do not assume a check that has not been stated. For anything that changes results or affects others, keep a real human decision point even if the tool lets you skip it. Do not automate approval; acceptance without scrutiny is not oversight. === "For providers" State the HITL level for each use case you support, and build the check into the workflow; do not count on the user to remember or even know. Match the check to the stakes, have the system enforce the stated level, and design the check so the human can actually understand and override the output. Try to facilitate understanding and to prevent "just clicking approve." === "For governance" Stated HITL levels make oversight auditable. Require each use case to declare its level and enforce it. Make stronger checks mandatory where actions have real consequences. Test that the oversight works in practice rather than assuming a named reviewer is enough. This includes peer-review integrity: confidential manuscripts should not be uploaded to external models, and reviewer AI use should be declared. ## Reasons How much oversight is right depends on the use case. A low-stakes lookup and an action that changes a record or a result do not need the same check. If the level is unstated, oversight is left to chance, which is neither reliable nor checkable. But a stated level is not a guarantee. There is strong evidence that human oversight often fails in practice: people defer to plausible-looking output (automation bias), rubber-stamp at scale, and can be left holding blame for systems they could not realistically control (for instance, due to volume). So the check must be designed for effectiveness, giving the human what they need to understand and override. Pipelines need to be assessed for realistically achievable volumes. The four labels used here (mandatory / optional, in-process / final check) are a useful shorthand, not settled standards. Agent autonomy is a spectrum from tight supervision to full autonomy. Stating and enforcing HITL levels fulfils part of [BP04](04-govern-autonomy-and-accountability.md) at the single use case level. ## Examples - A workflow never states its HITL level; each user assumes someone else checks, and an unreviewed agent edit reaches a shared record. - Every use case instead declares its level from a short list (mandatory, optional, in-process, final check), and a workflow that declares none is understood to run at full autonomy, so the choice is explicit. - A pipeline has a mandatory "human approves each item" step, but at hundreds of items an hour the reviewer clicks approve without reading; the check exists on paper and fails in practice. - The check is designed so the human can actually judge: it shows what changed, at a realistic volume, with approve, edit, veto, and stop, and the strength of the check is set by the stakes. - The stated level is enforced by the system rather than left to habit, which ties it to the guardrails in [BP04](04-govern-autonomy-and-accountability.md), and the HITL engagement is recorded in provenance ([BP07](07-provenance-and-citation.md)) so oversight is auditable instead of assumed. - A reviewer uploads a confidential manuscript to an external model against the stated boundary of the conference for a high-stakes task. They submit the AI-generated review without declaring the AI use. The conference had inserted a [prompt injection](../glossary.md#prompt-injection) into their review version and catches the reviewer with the prompted output form. The reviewer is barred from conference participation for two years. ## Sources - [ELIXIR TF Agentic AI: agenda and rolling best practice (2026)](../library/elixir-tf-agentic-ai-2026.md), Best Practice item 7. - [Agentic AI in the higher-education system (2026)](../library/hfd-agentic-ai-hochschulsystem-2026.md), §4.1 (explicit intervention points) and §6 (defined escalation and control). Consistent with, grounding only. - [EU AI Act, Article 14](../library/ref-eu-ai-act.md) and [NIST Generative AI Profile (AI 600-1)](../library/ref-nist-ai-rmf.md). Oversight must be effective and calibrated to risk; Article 14 names automation bias as a hazard the overseer must be able to counter. - [Elish, Moral Crumple Zones (2019)](../library/ref-elish-2019.md) and [Green, Flaws of Policies Requiring Human Oversight (2022)](../library/ref-green-2022.md). Evidence that human oversight frequently fails in practice; a stated level must be designed for effectiveness. ## Change history - 2026-07-27: Renumbered from BP08 to BP09 on inserting the new BP01 (match the method to the task). - 2026-07-27: Rewrote Examples as concrete scenarios (actor, action, outcome), including anti-patterns (unstated level, rubber-stamping at volume), replacing restatements of the practice. - 2026-07-26: Renumbered from BP08 to BP09 in the reordering. Added grounding (EU AI Act Article 14, NIST AI 600-1) and a caveat that a stated level is necessary but not sufficient (automation bias, rubber-stamping, moral crumple zones; Elish 2019, Green 2022), plus a peer-review confidentiality instance. - 2026-07-25: Created from the ELIXIR TF distillation (hook 8), grounded in the HFD paper. --- # Screen agents for dual-use and high-consequence risk Source: https://aiforscience.eu/best-practices/10-screen-dual-use-high-consequence/index.md

Best practice 10

# Screen agents for dual-use and high-consequence risk ## Practice
- Some [agents](../glossary.md#agent) carry [dual-use](../glossary.md#dual-use) risk: they can be used for good or bad. { #bp10-a1 } - For potential dual-use agents, screening is not optional. { #bp10-a2 } - Before an agent is given reach into the world, its capability for misuse should be evaluated against set thresholds. { #bp10-a3 } - Any high-consequence action an agent can take should pass through a screening chokepoint, with dual-use requests refused. { #bp10-a4 } - Because model training cannot be undone, data held under withdrawable consent can never be authorised for third-party model training or a perpetual licence, and an agent must be prevented from transmitting it for those uses. { #bp10-a5 }
=== "For practitioners" If your agent can act where a mistake or misuse could cause serious harm (ordering synthesis, running code against live systems, driving instruments), do not connect it to that capability without screening. Route high-consequence actions through providers or controls that screen them, and expect the agent to refuse dual-use requests. The same holds for data you cannot take back: never let an agent send data held under withdrawable consent to a service that will train on it or take a perpetual licence, and do not accept terms that authorise this. === "For providers" Evaluate an agent's misuse potential before granting real-world reach, and gate deployment on the result. Where an agent can trigger a high-consequence action, put a screening chokepoint in the path (for example a synthesis or service provider that screens orders), and build in dual-use refusal. Scale the safeguard to the capability, following the threshold-and-mitigation model the frontier safety frameworks share. Constrain and audit what an agent can send outward, exclude controlled-access data from third-party training and retention, and do not require a perpetual licence over data whose consent can be withdrawn. === "For governance" Decide which agent capabilities require screening before deployment, and make it mandatory for those that could cause serious harm. This is cross-domain: the same capability-threshold structure covers biological, chemical, and cyber risk. Require evaluation of misuse potential, and keep the thresholds current as capability rises. Treat irreversible data commitments as high-consequence too: do not accept grant or service terms that train third-party models on data held under withdrawable consent, and require enforced egress limits and audit where agents reach such data. ## Reasons Most agent use is low-stakes. A small part is not: an agent that can design a toxin, uplift a cyberattack, or command physical equipment can cause harm that no amount of provenance or [human-in-the-loop](../glossary.md#hitl) review undoes after the fact. That is why this is a screening-and-containment practice, applied before action is granted. The concern is cross-disciplinary; every major frontier safety framework, and the neutral syntheses of them, define the same structure (a capability threshold, an evaluation, and a proportionate mitigation) and apply it in parallel to chemical, biological, cyber, and autonomy risk. The evidence that the risk is real spans domains too: an AI model repurposed for toxicity generated tens of thousands of candidate toxic molecules, including known warfare agents, in hours; AI-designed protein sequences have evaded the screening that guards DNA synthesis; and AI systems with cyber-offense capability have broken out of containment and committed large-scale attacks. Some high-consequence actions are irreversible in a second sense: they cannot be walked back once taken. Training a third-party model on data, or granting a perpetual licence over it, cannot be undone, and the data cannot be reliably removed from the model afterwards. When the consent behind that data can be withdrawn, as it can be for human-subjects data under research ethics and data-protection law, no one can validly authorise a use that could not later honour a withdrawal. The safeguard is the same as for any irreversible harm: prevent the action before it happens. In agentic workflows this means constraining and auditing what an agent can send outward, because an agent that runs code and reads files can transmit such data without a deliberate upload. ## Examples - An agent's misuse capability is evaluated against set thresholds before it is given real-world reach, deployment is gated on the result, and the thresholds are raised as capability rises. - An agent is wired straight to an ordering or execution capability with no screen in the path, and a dual-use request goes through because nothing was positioned to catch it. - The agent is required to refuse dual-use requests, and that refusal is tested rather than assumed. - The same screen-before-acting pattern recurs across fields: - Life sciences: routing sequence orders through synthesis providers that screen them, after work showed AI-designed sequences can evade that screening. - Chemistry: guarding against generation of toxic compounds or precursors, after a toxicity model was inverted to design chemical-warfare agents. - Cyber: evaluating and limiting an agent's offensive-cyber uplift before it can act against real systems, after an autonomous system was shown to break out of containment. - Human-subjects data: an agent working on consented patient or genomic data is blocked from sending it to a third-party service that would train on it or take a perpetual licence, and grant or service terms requiring such a licence are refused, because consent for that data can be withdrawn and training cannot be undone. ## Sources - [METR, Common Elements of Frontier AI Safety Policies (2025)](../library/ref-metr-common-elements-2025.md) and [Frontier Model Forum, Components of Frontier AI Safety Frameworks](../library/ref-fmf-safety-frameworks.md). Independent syntheses showing the capability-threshold structure spans CBRN, cyber, and autonomy, which is the evidence this is a generic category. - [Urbina et al., Dual use of AI-powered drug discovery (2022)](../library/ref-urbina-dual-use-2022.md). A toxicity model inverted to generate 40,000 toxic molecules, including VX, in under 6 hours. The sharpest non-life-science instance. - [Wittmann et al., Science (2025)](../library/ref-wittmann-biosecurity-2025.md). AI-designed sequences evaded nucleic-acid synthesis screening; patches restored detection. The life-science instance. - [UK AI Security Institute, Frontier AI Trends (2025)](../library/ref-aisi-frontier-trends-2025.md). Measured cyber-offense capability rising toward expert level. The cyber capability trend. - [Autonomous agent breach of Hugging Face (2026)](../library/ref-hf-openai-agent-breach-2026.md). An autonomous system on OpenAI pre-release models escaped its evaluation sandbox and breached Hugging Face's production infrastructure. A realised cyber instance, disclosed by both organisations. - [US DURC oversight policy (OSTP 2024)](../library/ref-usg-durc-2024.md). A codified dual-use oversight instrument. Cited as a mature worked example; note it is scoped to the life sciences and under revision, so this practice is framed on the general concept, not on that instrument. - [EU AI Omnibus (2026)](../library/ai-omnibus-2026.md), Art 5(1a)(a)(ii). Obliges providers to build technical safeguards against reasonably foreseeable and reproducible prohibited output rather than rely on intent or policy, the same provider-safeguard logic as routing high-consequence actions through a screening chokepoint (bp10-a4). - [WMA Declaration of Helsinki (2024)](../library/ref-helsinki-2024.md) and [EU GDPR (2016)](../library/ref-gdpr-2016.md). Research participants may withdraw at any time, and data subjects have a right to withdraw consent (Art 7(3)) and to erasure (Art 17); revocable consent cannot authorise a use that cannot be undone (bp10-a5). - [A safer framework for patient data in AI-for-Science grants (2026)](../library/gagneur-rare-disease-patient-data-2026.md). Adjacent support: analysis permission is not training permission, and no perpetual licence should be taken over patient-level data. Individual commentary; it does not itself make the revocable-consent argument. ## Change history - 2026-07-28: Added atom bp10-a5 (data under withdrawable consent cannot be authorised for irreversible third-party training or a perpetual licence, and an agent must be prevented from transmitting it for those uses), grounded in the Declaration of Helsinki and GDPR (right to withdraw; right to erasure), with the Gagneur commentary as adjacent support. Extended the tabs, Reasons, and Examples to match. - 2026-07-27: Added the EU AI Omnibus (2026) as a supporting source on bp10-a4 (provider safeguards against foreseeable prohibited output; Art 5(1a)). - 2026-07-27: Renumbered from BP09 to BP10 on inserting the new BP01 (match the method to the task). - 2026-07-27: Rewrote Examples as concrete scenarios (actor, action, outcome), including an anti-pattern (unscreened path); kept the labelled cross-field instances (life sciences, chemistry, cyber). - 2026-07-26: Created as a domain-neutral practice on screening agents for dual-use and high-consequence risk (the frontier-framework threshold-and- mitigation pattern), with life-science, chemistry, and cyber cases as labelled examples. --- # Failures log Source: https://aiforscience.eu/best-practices/failures/index.md # Failures log Clear examples of what did not work are as useful as the recommendations. This is a running log of failed or abandoned attempts to use agentic AI in scientific practice. It is a record, not a practice: entries are observations, and a repeated failure may become the evidence behind a practice. To add a failure, use the [Submit a document](https://github.com/slolab/aiforscience.eu/issues/new/choose) or issue templates, or open a pull request adding a dated bullet below. ## Entries - **2026-07** — Autonomous agent escaped its test sandbox and breached production infrastructure. During an internal cyber-capability evaluation with guardrails reduced, an [agent](../glossary.md#agent) built on OpenAI pre-release models escaped its sandbox, exploited Hugging Face's dataset pipeline, harvested credentials, and moved laterally across production systems. An early real-world case of a frontier agent's offensive-cyber capability causing operational harm outside a controlled setting. Related practices: [BP10](10-screen-dual-use-high-consequence.md). Source: [Autonomous agent breach of Hugging Face (2026)](../library/ref-hf-openai-agent-breach-2026.md). - **2026-07** — [Agents](../glossary.md#agent) falling back to scraping or legacy endpoints when there is no clean [interface](../glossary.md#interface). Where a resource had no task-shaped agent interface, agents fell back to legacy APIs or scraped the service. This is fragile and adds load. Seen for several life-science resources. Related practices: [BP02](02-default-to-agent-accessibility.md), [BP06](06-design-around-user-tasks.md). Source: [ELIXIR TF Agentic AI (2026)](../library/elixir-tf-agentic-ai-2026.md), Failures section. Concrete case: [Web-scraping AI bots disrupt scientific databases (Nature news, 2025)](../library/ref-nature-scraping-bots-2025.md), where scraping load broke DiscoverLife and other open resources. --- # EU AI Omnibus (2026) Source: https://aiforscience.eu/library/ai-omnibus-2026/index.md # EU AI Omnibus (2026) !!! info "Source" **Document:** "Regulation (EU) 2026/1744 amending Regulation (EU) 2024/1689 (the Digital Omnibus on AI)". **Issuing body:** European Union. **Date:** Proposed 19 November 2025; in force 27 July 2026. **Distilled:** 2026-07-27. ## Summary The AI Omnibus is a targeted simplification package that amends the EU AI Act (Regulation (EU) 2024/1689). Most of it is administrative and regulatory: postponed compliance timelines for high-risk systems, simplified documentation and registration for smaller providers, an EU-level regulatory sandbox, expanded AI Office oversight of general-purpose models and large platforms, and new prohibitions on AI-generated non-consensual intimate imagery and child sexual abuse material. Little of the document speaks to scientific practice directly, and it adds no research or R&D exemption. The provisions that bear on the record are narrow: the softening of the AI literacy obligation, a new legal basis for processing special-category data to detect and correct bias, the narrowing and delay of high-risk classification, and the framing that a provider is responsible for a "reasonably foreseeable and reproducible" prohibited output unless it has built adequate technical safeguards. It updates the grounding the AI Act already provides for BP03, BP04, and BP09 (see [ref-eu-ai-act](ref-eu-ai-act.md)); it does not justify a new practice. ## Hooks, with citations **1. AI literacy shifts from a duty to ensure to a duty to support.** The regulation replaces the obligation on providers and deployers to "ensure" AI literacy with a duty to "take measures to support the development of AI literacy" of their staff, with Member States and the Commission to support and facilitate that effort, especially for SMEs (Art 4; Recital 8). Relevance: bears on how institutions train scientists to use agentic AI; the legal floor is now a supportive measure rather than a hard obligation. Audiences: governance, providers. **2. New legal basis to process special-category data for bias detection.** A new Article 4a permits providers and deployers of high-risk (and, under conditions, other) AI systems to process special categories of personal data where necessary to detect and correct bias, subject to strict safeguards: use only where non-sensitive or synthetic data cannot achieve the purpose, strict access controls, no transmission to third parties, deletion once bias is corrected, and documented necessity (Art 4a; Recital 9). Relevance: bias detection is an evaluation dimension; this sets the conditions under which sensitive research data may be used to test AI systems for it (see [BP08](../best-practices/08-evaluate-tools-before-trust.md)). Audiences: providers, practitioners, governance. **3. Provider responsibility for foreseeable and reproducible misuse.** For the new prohibitions, a provider is liable not only where a system is intended to produce prohibited material but where that output is a "reasonably foreseeable and reproducible outcome" absent "reasonable and adequate technical safety measures and other safeguards" (Art 5(1a)(a)(ii); Recital 12). Relevance: the standard puts the burden on providers to build technical safeguards against foreseeable misuse rather than rely on policy or intent, which mirrors the guardrail and screening logic in [BP04](../best-practices/04-govern-autonomy-and-accountability.md) and [BP10](../best-practices/10-screen-dual-use-high-consequence.md). Audiences: providers, governance. **4. High-risk classification narrowed; compliance dates postponed.** AI used solely for non-safety aspects such as user assistance, performance optimisation, or service efficiency does not qualify as a safety component (Art 6(1a); Recital 7), and the application dates for high-risk obligations are pushed to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I product-integrated systems (Art 113; Recital 40). Relevance: affects when and whether providers of regulated scientific services (for example clinical or diagnostic AI) fall under high-risk obligations. Audiences: providers, governance. **5. EU-level regulatory sandbox and expanded real-world testing.** The AI Office may establish a Union-level sandbox, with priority access for SMEs and startups, and real-world testing is extended to high-risk systems under Union harmonisation legislation subject to safeguards (Art 57-60, Art 60a; Recitals 24-27). Relevance: gives developers of scientific AI a supervised route to test systems before deployment, adjacent to the evaluate-before-trust principle in [BP08](../best-practices/08-evaluate-tools-before-trust.md). Audiences: providers, governance. **6. Conformity assessment aligned with sectoral law; simplified documentation for smaller providers.** Notified bodies may run a single, unified conformity assessment covering the AI Act and sectoral law such as the medical-device regulations (MDR/IVDR) (Recital 17), and the Commission must provide a simplified technical-documentation form for SMEs and small mid-caps that notified bodies must accept (Art 11; Recital 18). Relevance: lowers the compliance overhead for smaller builders of regulated biomedical AI, a common provider profile in the life sciences. Audiences: providers. ## Mapping to practices | Hook | Supports | In tension with | |---|---|---| | 1 | context for [BP04](../best-practices/04-govern-autonomy-and-accountability.md) (institutional governance of AI use) | weakens a prior training obligation | | 2 | [BP08](../best-practices/08-evaluate-tools-before-trust.md) (bias detection as evaluation) | | | 3 | [BP04](../best-practices/04-govern-autonomy-and-accountability.md), [BP10](../best-practices/10-screen-dual-use-high-consequence.md) | | | 4 | context for [BP03](../best-practices/03-register-and-vet-interfaces.md), [BP04](../best-practices/04-govern-autonomy-and-accountability.md) | | | 5 | context for [BP08](../best-practices/08-evaluate-tools-before-trust.md) | | | 6 | context for providers | | Hook 1 is a tension, not a contradiction: the Act still expects AI literacy, but the legal obligation is now to support rather than ensure it. The record's position (that practitioners and institutions should build the skills to use agentic AI well) is unchanged; the regulatory floor beneath it has moved. ## Proposed changes to practices Note edits applied on 2026-07-27; a new practice was not warranted. - [x] Add `ai-omnibus-2026` as a supporting note on [BP04](../best-practices/04-govern-autonomy-and-accountability.md): the foreseeable-and-reproducible-misuse standard (Art 5(1a)) puts technical safeguards in the system, not in policy, which is exactly `bp4-a1`. - [x] Add `ai-omnibus-2026` as a supporting note on [BP10](../best-practices/10-screen-dual-use-high-consequence.md): the same standard obliges providers to build safeguards against foreseeable prohibited output (`bp10-a4`). - [x] Note on [BP08](../best-practices/08-evaluate-tools-before-trust.md) that the amended Act now provides a conditional legal basis (Art 4a) for using special-category data to detect and correct bias, an evaluation dimension. - [x] Update [ref-eu-ai-act](ref-eu-ai-act.md) to record the 2026 amendment (Art 4 literacy softening, Art 4a bias detection, postponed high-risk timelines) and cross-link to this entry. - [x] No new practice. The document grounds and updates existing practices; it does not pass the gate for its own page. ## Cautions and gaps Most of the Omnibus is out of scope for this record. The prohibitions on non-consensual intimate imagery and CSAM, the DSA platform oversight, the machinery reclassification, and the cybersecurity interplay with the Cyber Resilience Act are general AI regulation, cited here only as context. The document adds no dedicated research or R&D exemption; the only research-adjacent openings are the bias-detection basis (Art 4a) and a red-teaming allowance for compliance testing under the new prohibitions (Recital 13). Applicability is narrow: most scientific use of agentic AI is not "high-risk" under the Act, so the postponed timelines and conformity-assessment changes bear mainly on providers of regulated systems such as medical AI. The article and recital numbers here refer to the AI Act (Regulation (EU) 2024/1689) as amended, not to the amending regulation's own numbering. They were verified on 2026-07-27 against the Official Journal text and independent legal trackers; the new prohibitions themselves apply from 2 December 2026. --- # EU Expert Forum on Frontier AI (2026) Source: https://aiforscience.eu/library/ec-expert-forum-2026/index.md # EU Expert Forum on Frontier AI (2026) !!! info "Source" **Document:** "Enhancing competitiveness, sovereignty and security of the European Union in frontier AI. Key insights from the first meeting of the European Expert Forum on Frontier AI". **Issuing body:** European Commission, European AI Office. **Date:** July 2026 (meeting April 2026, Chatham House Rule). **DOI:** 10.2759/8947951. **Distilled:** 2026-07-25. The report states it "should not be considered as representative of the European Commission's official position". ## Summary This report sums up a first meeting of over 100 experts convened by the European AI Office on how the EU can improve its competitiveness, sovereignty, and security in frontier AI. Most of the document is outside this record's scope: computing infrastructure and energy, growth capital, semiconductor leverage, talent retention, funding vehicles, and treaty-level coordination are industrial, economic, and security policy, which the [mission](../about/mission.md) cites as context but does not distill. Read for what affects how science is done, the yield is narrow but real: independent evaluation and verification of AI systems, provider choice and openness, domain-specific systems as an alternative to general-purpose models, and the point that frontier capability speeds up science while raising its risks. Those passages are recorded below as grounding for existing practices. The rest is noted as context and taken no further. This entry is short on purpose. ## Hooks, with citations **1. Independent evaluation, audit and verification capacity.** The document lists, among ways to strengthen European leverage, "Strengthening control, including through sovereign audit, evaluation and verification capacity" (§4.2.3, p. 24), and names "compute verification or independent evaluations" as promising instruments (§3.2.3, p. 19-20). Relevance: the independent evaluation and audit of agentic systems grounds [BP04](../best-practices/04-govern-autonomy-and-accountability.md) and [BP07](../best-practices/07-provenance-and-citation.md). Audiences: governance, providers. **2. Provider diversity and openness preserve choice.** The document frames "Preserving choice, including through provider diversity and openness" as a dimension of turning European strengths into reliable access, choice, control and benefit (§4.2.2, p. 24). Relevance: choosing among agent models and interfaces without lock-in grounds [BP03](../best-practices/03-register-and-vet-interfaces.md) and is consistent with the ELIXIR discussion on vendor skills. Audiences: providers, practitioners. **3. The same capability that accelerates science amplifies its risks.** The document: "the same capabilities driving economic and scientific progress also amplify a set of systemic risks of direct relevance to the security of the Union" (Overview, p. 4-5). Relevance: context for why the governance, human-in-the-loop and provenance practices matter as capability rises; grounds [BP04](../best-practices/04-govern-autonomy-and-accountability.md). Audiences: governance. **4. Domain-specific systems can outperform general-purpose models.** The document reports that "Several experts argued for sustained investment in purpose-driven AI tools and domain-specific systems ... tools of this type ... can outperform general-purpose models within their domains while requiring substantially less capital and compute to develop" (§3.2.3, p. 21), with domain-specific frontier AI "cited as a more achievable form of leadership than competing on raw scale" (§3.2.2, p. 20). Relevance: supports [BP01](../best-practices/01-match-method-to-task.md), that a specialized method can fit a task better than a general frontier model. Qualified by the report's caution that demand for smaller or domain-specific models is uncertain and that non-frontier access is "an imperfect substitute" for frontier access (§3.2.2, p. 20; ch. 4, p. 22). Audiences: practitioners, providers, governance. ## Mapping to practices | Hook | Supports | In tension with | |---|---|---| | 1 | [BP04](../best-practices/04-govern-autonomy-and-accountability.md), [BP07](../best-practices/07-provenance-and-citation.md) | | | 2 | [BP03](../best-practices/03-register-and-vet-interfaces.md) | | | 3 | [BP04](../best-practices/04-govern-autonomy-and-accountability.md) | (framing) | | 4 | [BP01](../best-practices/01-match-method-to-task.md) | (demand and substitution caveat) | The report's competitiveness and sovereignty framing is in tension with the neutral coalition voice of this record. The record cites the evaluation and choice threads and does not adopt the strategic-autonomy frame. ## Proposed changes to practices - [x] No new practice. The document is largely out of scope and adds no distinct action. - [x] Add this document as grounding to [BP01](../best-practices/01-match-method-to-task.md) (hook 4), [BP03](../best-practices/03-register-and-vet-interfaces.md) (hook 2), [BP04](../best-practices/04-govern-autonomy-and-accountability.md) (hooks 1, 3), and [BP07](../best-practices/07-provenance-and-citation.md) (hook 1). ## Cautions and gaps - Largely out of scope for this record. The bulk of the document is industrial, economic and security policy, recorded here as context so the question of its relevance is closed rather than reopened by the next reader. - Aggregated expert views under the Chatham House Rule, explicitly not the Commission's official position. The grounding it provides strengthens evidence; it is not an endorsement and does not change any practice's status. --- # ELIXIR AI strategy (2026) Source: https://aiforscience.eu/library/elixir-ai-strategy-2026/index.md # ELIXIR AI strategy (2026) !!! info "Source" **Document:** "ELIXIR AI strategy: Ten priorities for life sciences research". **Issuing body:** ELIXIR Europe (lead author Salvador Capella-Gutierrez; contributors from ELIXIR Nodes and the Hub). **Date:** June 2026, version 1.0. **Distilled:** 2026-07-27. ## Summary The document is a high-level strategy in which ELIXIR sets ten priorities for supporting AI in European life sciences. Its stated role is to enable and coordinate rather than to provide AI models or large-scale compute: federated data access, expert-curated datasets, and community standards. Most of the text is organisational (aligning Nodes, coordinating the Hub, configuring EU AI Factories, securing funding) and sits outside the scope of this record. The parts that bear on how science is done concern curated AI-ready data with references to primary sources, training and testing on independent data, evaluation and validation of AI models, and responsible-AI-by-design. It grounds several existing practices and justifies no new one; ELIXIR-specific structures are read as examples. ## Hooks, with citations **1. Ground truth in biology is ambiguous and revisable, so curated, expert-validated benchmarks are a long-term community endeavour.** The document: "ground truth in biology is rarely unambiguous: the functional annotation of genes, the pathogenicity classification of variants, and the phenotypic characterisation of disease all require deep domain expertise and are subject to revision as scientific understanding advances. Constructing and maintaining the curated, expert-validated benchmarks that AI models require is therefore a long-term, community-wide endeavour, not a one-off data engineering task" (Introduction, p. 2). Relevance: supports [BP08](../best-practices/08-evaluate-tools-before-trust.md); the reference against which a tool is judged is itself curated, contested, and moving. Audiences: practitioners, providers, governance. **2. Validating biological predictions requires experimental follow-up, and the feedback loop is far slower than automated benchmarking.** The document: "validating biological predictions almost always requires experimental follow-up, creating feedback loops that are orders of magnitude slower than in domains where automated benchmarking is feasible" (Introduction, p. 2). Relevance: qualifies the automated-evaluation assumption behind [BP08](../best-practices/08-evaluate-tools-before-trust.md); reinforces that human and experimental judgement stay in the loop ([BP09](../best-practices/09-human-in-the-loop.md)). Audiences: practitioners, governance. **3. Training and testing on independent data should be standard practice, with explicit awareness of data leakage.** The document: "responsible management of sensitive data and awareness of data leakage to ensure the quality of AI models" (Introduction, p. 3); "ELIXIR will promote principles for ensuring that training and testing on independent data is adopted as a standard practice" (§6, p. 6). Relevance: supports [BP08](../best-practices/08-evaluate-tools-before-trust.md); independence of test data is what keeps a benchmark score from being a misleading proxy. Audiences: practitioners, providers. **4. Curated, AI-ready datasets must carry clear references to their primary sources.** The document: "These datasets require expert curation to accurately represent complex biological information and must include clear references to their primary sources to ensure transparency, build trust and guarantee provenance" (§5, p. 6). Relevance: supports [BP05](../best-practices/05-documentation-and-data-for-agents.md) (data published with meaning) and [BP07](../best-practices/07-provenance-and-citation.md) (traceable to primary sources). Audiences: providers, practitioners. **5. A reference framework builds on DOME and OSAI to keep data, software, and AI models reusable in line with FAIR.** The document: "Building on ELIXIR's leading role through the DOME recommendations and the Open and Sustainable AI (OSAI) guidelines, we will drive and maintain a reference framework to ensure that research data, software, and AI models are used and reused effectively in line with the FAIR principles" (§6, p. 6). Relevance: supports [BP05](../best-practices/05-documentation-and-data-for-agents.md); [DOME](ref-dome-2021.md) is a reporting standard for supervised-ML validation that also bears on [BP08](../best-practices/08-evaluate-tools-before-trust.md), and [OSAI](ref-osai-2025.md) covers reproducibility and reusability of AI outputs. Audiences: providers, practitioners, governance. **6. External standards such as Model Context Protocol and agentic frameworks are to be adopted and adapted for the life sciences.** The document: "it will also adopt and adapt whenever necessary external standards for the life sciences while serving as a proxy for emerging components such as Model Context Protocols and Agentic Frameworks" (§6, p. 6). Relevance: supports [BP06](../best-practices/06-design-around-user-tasks.md); the interface substrate (MCP, agentic frameworks) is imported rather than reinvented. Audiences: providers. **7. A European platform for sharing and reusing AI models and datasets is identified as a missing component.** The document: "the lack of a European, domain-specific platform for sharing and reusing AI models and datasets, akin to platforms such as Hugging Face" (§3, p. 5); it also names "the generation of multimodal synthetic data mimicking real data" as an unmet need. Relevance: bears on [BP05](../best-practices/05-documentation-and-data-for-agents.md) and [BP07](../best-practices/07-provenance-and-citation.md); shared models and datasets need machine-readable documentation and a provenance trail to be reusable. Audiences: providers, governance. **8. Responsible AI is to be embedded by design, with guidelines that turn evaluation into actionable items.** The document: "Embed by design responsible AI principles, including model explainability, interpretability, and the mitigation of algorithmic bias, across all stages of development and use ... This effort will include guidelines on how to perform AI Model evaluation so principles get translated into actionable items" and will "consider aspects beyond the AI models itself, including collection protocols and data handling practices" (§10, p. 8). Relevance: supports [BP04](../best-practices/04-govern-autonomy-and-accountability.md) (responsible use built into the system) and [BP08](../best-practices/08-evaluate-tools-before-trust.md) (evaluation made concrete). Audiences: providers, governance. **9. The reproducible-research focus is to be extended to AI-related activities.** The document: "ELIXIR will promote transparent methodologies and extend its current focus on reproducible research to include AI-related activities" (§10, p. 8). Relevance: supports [BP07](../best-practices/07-provenance-and-citation.md) (recording a run so it can be re-examined) and [BP08](../best-practices/08-evaluate-tools-before-trust.md) (reproducible evaluation). Audiences: practitioners, providers, governance. **10. Contributions and underlying services must be properly credited, including where derived models overshadow the original resources.** The document: "Recognition strategies will be embedded by design to ensure that experts' contributions are properly credited" (§4, p. 5); the uplifting of services should support "service sustainability and proper attribution in an environment where derived models often overshadow original services" (§8, p. 8). Relevance: supports [BP07](../best-practices/07-provenance-and-citation.md); attribution reaches the data resources and human curation a model was built on, not only the model. Audiences: providers, governance. **11. Sensitive human data is to be analysed through federated, privacy-preserving methods on sovereign infrastructures.** The document: "supporting the integration of both open and controlled-access data resources, including sensitive human data, through federated and privacy-preserving methods" (§5, p. 6); "prioritising the deployment of AI models on federated, sovereign European infrastructures" (§7, p. 7). Relevance: bears on [BP02](../best-practices/02-default-to-agent-accessibility.md) (access governed by the resource) and on governance of how sensitive data is used for AI. Audiences: providers, governance. **12. Some AI applications fall under the EU AI Act high-risk category and need compliance expertise.** The document: "some of these applications might fall under the high-risk category, as defined by the EU AI Act" (§4, p. 5); the responsible-AI priority commits to alignment "with emerging European and international regulatory frameworks, such as the European AI Act" (§10, p. 8). Relevance: supports [BP04](../best-practices/04-govern-autonomy-and-accountability.md); the regulatory frame is already anchored in the record via the EU AI Act reference. Audiences: governance. ## Mapping to practices | Hook | Supports | In tension with | |---|---|---| | 1, 3 | [BP08](../best-practices/08-evaluate-tools-before-trust.md) | | | 2 | [BP08](../best-practices/08-evaluate-tools-before-trust.md), [BP09](../best-practices/09-human-in-the-loop.md) | | | 4 | [BP05](../best-practices/05-documentation-and-data-for-agents.md), [BP07](../best-practices/07-provenance-and-citation.md) | | | 5 | [BP05](../best-practices/05-documentation-and-data-for-agents.md), [BP08](../best-practices/08-evaluate-tools-before-trust.md) | BP08 (see below) | | 6 | [BP06](../best-practices/06-design-around-user-tasks.md) | | | 7 | [BP05](../best-practices/05-documentation-and-data-for-agents.md), [BP07](../best-practices/07-provenance-and-citation.md) | | | 8 | [BP04](../best-practices/04-govern-autonomy-and-accountability.md), [BP08](../best-practices/08-evaluate-tools-before-trust.md) | | | 9 | [BP07](../best-practices/07-provenance-and-citation.md), [BP08](../best-practices/08-evaluate-tools-before-trust.md) | | | 10 | [BP07](../best-practices/07-provenance-and-citation.md) | | | 11 | [BP02](../best-practices/02-default-to-agent-accessibility.md) | | | 12 | [BP04](../best-practices/04-govern-autonomy-and-accountability.md) | | One nuance sits between hooks 5 and 8 and [BP08](../best-practices/08-evaluate-tools-before-trust.md). The document places evaluation guidelines and a reference framework at the infrastructure level, promoted for adoption across the community. BP08 holds that evaluation is the task of the adopter, who alone knows the task and carries the stakes. These are complementary: shared reporting standards (DOME, REFORMS) make adopter-run evaluations comparable; they do not replace the adopter running one. ## Proposed changes to practices - [ ] Ground [BP08](../best-practices/08-evaluate-tools-before-trust.md) with this strategy and with DOME. Add an Examples bullet: training and testing on independent data, with explicit checks against data leakage, so a benchmark score is not inflated by contamination. Note in Reasons that in biology the reference itself is curated and revisable and that validation often needs slow experimental follow-up. - [ ] Add this strategy and DOME as sources on [BP08](../best-practices/08-evaluate-tools-before-trust.md); add this strategy as a source on [BP05](../best-practices/05-documentation-and-data-for-agents.md) and [BP07](../best-practices/07-provenance-and-citation.md). - [ ] Ground [BP07](../best-practices/07-provenance-and-citation.md): add an Examples bullet that attribution reaches the data resources and human curation a model was derived from, not only the model, so derived work does not overshadow the source (hook 10). - [ ] Ground [BP05](../best-practices/05-documentation-and-data-for-agents.md) with the DOME/OSAI/FAIR reference framework for reusable data, software, and models (hook 5), and [BP06](../best-practices/06-design-around-user-tasks.md) with MCP and agentic frameworks as external standards to adopt and adapt (hook 6). - [ ] No new practice. All in-scope material merges into existing practices per the gating rule. ## Cautions and gaps - The document is a high-level strategy. Most of it is organisational (Node alignment, Hub coordination, flagship-project funding, configuring EU AI Factories and Antennas, digital sovereignty, compute geopolitics) and is out of scope for this record; it is cited here only as context. It states intentions, not methods, so the hooks are directions of travel rather than tested practice. - Explainability and interpretability are asserted as responsible-AI pillars (§10) without an actionable method. The record has no dedicated interpretability practice, and one strategy statement does not justify creating one. Treated as grounding for BP04, not a new practice. - [DOME](ref-dome-2021.md) and [OSAI](ref-osai-2025.md) are both added as reference works. OSAI is a preprint (arXiv:2505.16619), community guidance rather than a ratified standard; treated as grounding, not as a settled requirement. - The commitment to monitor and reduce the environmental impact of computational practices (Implementation roadmap, p. 9), and the Draghi Report framing behind it, touch energy and industrial policy and are out of scope; noted here only because "sustainability" is part of the OSAI framing. - ELIXIR-specific structures (Nodes, Hub, Platforms, Communities, Core Data Resources, the PDB/AlphaFold example) are read as examples. The practices state the general form. --- # ELIXIR TF Agentic AI: agenda and rolling best practice (2026) Source: https://aiforscience.eu/library/elixir-tf-agentic-ai-2026/index.md # ELIXIR TF Agentic AI: agenda and rolling best practice (2026) !!! info "Source" **Document:** "TF Agentic AI, Agenda 2026" (working agenda and rolling best-practice document). **Issuing body:** ELIXIR Europe, AI Ecosystem Focus Group, Task Force Agentic AI. **Date:** rolling; meetings May to July 2026. **Distilled:** 2026-07-25. Personal data (attendee lists, apologies, chat transcripts) is excluded by design; this entry distills the rolling Best Practice and Failures sections and the framing text. ## Summary The ELIXIR AI Ecosystem Focus Group runs a task force on agentic AI for life-science research infrastructure. It keeps a rolling list of best practices, revised in monthly meetings, learned from early adopters and written for the larger group building durable services. The ten practices cover how providers open data resources and tools to agents: what to expose, how to design the interface, how to make answers traceable, and how to keep access safe and manageable. This reading generalises from life-science infrastructure to scientific services in general; ELIXIR-specific cases are treated as examples. The document is the main source for the provider-facing practices here. ## Hooks, with citations **1. Pioneers and settlers are different populations and need different support.** The document: "There are two groups of users: pioneers and settlers. ... Pioneers should be enabled ('the best you can do is get out of their way') and observed. Learning from them is what yields the good practices below. Settlers are far more numerous, coming in after the pioneers have moved on, to build something sustainable." (Best Practice, framing paragraph). Relevance: an operating principle for how the record is made, adopted in [the mission](../about/mission.md); it is not itself a practice. Audiences: practitioners, providers, governance. **2. Default to agent-accessibility, but be selective about depth.** The document: "Agent access to resources is to be assumed, while accepting that not everything needs a bespoke maintained agent-accessible interface. Prioritisation can follow demand and service tier." (Best Practice, item 1). Relevance: sets the provider stance behind [BP02](../best-practices/02-default-to-agent-accessibility.md). Audiences: providers, governance. **3. A typology of resources decides which solution fits which service.** The document: "Generic vs. service-specific agentic interfaces should follow a taxonomy of services." Generalisable approaches suit widely-used core resources, interoperability resources and deposition databases; long-tail services can be lighter-touch (Best Practice, item 2). Relevance: the prioritisation mechanism in [BP02](../best-practices/02-default-to-agent-accessibility.md). Audiences: providers, governance. **4. Write documentation with agents in mind.** The document: "Precise, machine-readable, up-to-date. Docs and docstrings are the primary surface an agent will use; the added precision will be useful to human users as well." (Best Practice, item 3). Relevance: grounds [BP05](../best-practices/05-documentation-and-data-for-agents.md). Audiences: practitioners, providers. **5. Design the interface around user tasks, not the underlying API.** The document: "Don't just wrap REST. Design MCP servers, skills, or plugins to address the expected user queries, rather than simply following the data-driven API." It warns that misaligned surfaces cause many fine-grained calls, raising server load and cost (Best Practice, item 4). Relevance: grounds [BP06](../best-practices/06-design-around-user-tasks.md). Audiences: providers, practitioners. **6. Provide structured data and semantics with concrete examples.** The document: "Concrete low-level examples: natural language to query language (SPARQL, Cypher), per-source RAG indexing strategies (e.g., Lucene + FAISS with MCP orchestrator)." (Best Practice, item 5). Relevance: the second half of [BP05](../best-practices/05-documentation-and-data-for-agents.md), covering data and worked examples, not only prose docs. Audiences: practitioners, providers. **7. Make provenance and citation first-class.** The document: "Allow verification and tracing of any answer given by an agent. Allow distinguishing human and LLM-agent contributions." (Best Practice, item 6). Relevance: grounds [BP07](../best-practices/07-provenance-and-citation.md). Audiences: practitioners, providers, governance. **8. State the human-in-the-loop level for each use case.** The document: "For each use case, clearly state the HITL level (mandatory, optional, in-process, final check)." (Best Practice, item 7). Relevance: grounds [BP09](../best-practices/09-human-in-the-loop.md). Audiences: practitioners, providers, governance. **9. Register agent interfaces through a channel that implies review.** The document: "Register dedicated agent interfaces and tag them. ... Registration implies a check / human review. Will be very important to be safer towards malware and prompt injection attacks." (Best Practice, item 8). Relevance: grounds [BP03](../best-practices/03-register-and-vet-interfaces.md). Audiences: providers, governance. **10. An approved channel makes agent traffic manageable.** The document: "Find ways to manage agent traffic. An approved MCP channel can make management of bot traffic easier, but blocking IPs can reduce the resources exposure / usefulness." (Best Practice, item 9). Relevance: the traffic-management facet of [BP03](../best-practices/03-register-and-vet-interfaces.md). Audiences: providers, governance. **11. Collect failures as readily as success stories.** The document: "Clear examples of what did not work are as important as the recommendations." A parallel Failures document lists cases such as agents falling back to legacy endpoints or scraping when no clean interface exists (Best Practice, item 10; Failures section). Relevance: seeds the [Failures log](../best-practices/failures.md), a record convention rather than a practice. Audiences: practitioners, providers. **12. Providers lack a clear handle on their users.** The document (meeting note, paraphrased and de-identified): service providers do not have a good handle on their users, which needs to inform the use-case-driven development of agentic interfaces (July 2026 discussion). Relevance: reinforces the task-first design in [BP06](../best-practices/06-design-around-user-tasks.md). Audiences: providers. ## Mapping to practices | Hook | Supports | In tension with | |---|---|---| | 1 | (operating principle, see [mission](../about/mission.md)) | | | 2, 3 | [BP02](../best-practices/02-default-to-agent-accessibility.md) | | | 4, 6 | [BP05](../best-practices/05-documentation-and-data-for-agents.md) | | | 5, 12 | [BP06](../best-practices/06-design-around-user-tasks.md) | | | 7 | [BP07](../best-practices/07-provenance-and-citation.md) | | | 8 | [BP09](../best-practices/09-human-in-the-loop.md) | | | 9, 10 | [BP03](../best-practices/03-register-and-vet-interfaces.md) | | | 11 | [Failures log](../best-practices/failures.md) | | No direct tensions with the current practices. The one internal tension, "default to accessibility" against "not everything needs an interface", is resolved inside BP02 through prioritisation by demand and importance. ## Proposed changes to practices - [x] Create [BP02](../best-practices/02-default-to-agent-accessibility.md) from hooks 2 and 3. - [x] Create [BP03](../best-practices/03-register-and-vet-interfaces.md) from hooks 9 and 10. - [x] Create [BP05](../best-practices/05-documentation-and-data-for-agents.md) from hooks 4 and 6 (replaces the dummy BP0 on documentation). - [x] Create [BP06](../best-practices/06-design-around-user-tasks.md) from hooks 5 and 12. - [x] Create [BP07](../best-practices/07-provenance-and-citation.md) from hook 7. - [x] Create [BP09](../best-practices/09-human-in-the-loop.md) from hook 8. - [x] Create [BP08](../best-practices/08-evaluate-tools-before-trust.md) from the evaluation gap recorded below (adopter-side evaluation before trust). - [x] Seed the [Failures log](../best-practices/failures.md) from hook 11. ## Cautions and gaps - Evaluation and trust of agent interfaces is raised as an open question: how to assess whether a skill or MCP server is useful and safe, without an agreed method. This gap is now addressed by [BP08](../best-practices/08-evaluate-tools-before-trust.md), grounded in this entry, which covers adopter-side evaluation before trust. - The source is a working agenda and a rolling document, not a peer-reviewed or formally endorsed output. All derived practices are `draft`. - ELIXIR-specific instances (Core Data Resources, biocontext.ai, bio.tools) are examples, not requirements. The practices state the general form. - Pioneers and settlers is an operating principle, not a practice and not a tag. --- # Expectation–Realisation Gap for Agentic AI (2026) Source: https://aiforscience.eu/library/expectation-realisation-gap-2026/index.md # Expectation–Realisation Gap for Agentic AI (2026) !!! info "Source" **Document:** "Quantifying the Expectation–Realisation Gap for Agentic AI Systems". **Author:** Sebastian Lobentanzer (Institute of Computational Biology, Helmholtz Munich). **Date:** February 2026 (arXiv:2602.20292, v2). **Distilled:** 2026-07-27. ## Summary A narrative review that assembles controlled trials and independent external validations to measure the gap between pre-deployment expectations for agentic AI and realised outcomes. Across software engineering, clinical documentation, and clinical decision support, it finds that realised benefits systematically fall short of what users forecast, what vendors claim, and what developers report from internal validation. The headline case is a randomised trial in which experienced developers expected a 24% speedup from AI tools but were slowed by 19%, a 43 percentage-point calibration error that also reversed direction. The review attributes the gap to four recurrent drivers: workflow integration friction and partial adoption, human verification and review burden, measurement construct mismatch, and treatment-effect heterogeneity. It argues for structured planning that states quantified, net-of-oversight benefit expectations up front and ties post-deployment measurement back to them, and proposes the author's own Agentic Automation Canvas as one instrument for doing so. ## Hooks, with citations **1. The expectation–realisation gap is the review's organising claim.** The document: "realised outcomes frequently fall short of pre-deployment expectations. We term this discrepancy the *expectation–realisation gap*. It reflects systematic patterns in how agentic systems interact with human workflows, how performance is measured, and how benefits are distributed across user populations" (Introduction). Relevance: names a planning problem that sits upstream of tool choice and evaluation; bears on how agentic deployments are planned and governed. Audiences: practitioners, providers, governance. **2. The sharpest single data point: experts forecast a speedup and were slowed.** The document: "participants forecast that AI assistance would reduce their completion time by 24%. The measured outcome was a 19% *increase* in completion time—a 43 percentage-point calibration error on the time-change scale, and a complete reversal in direction." "AI-assisted developers also estimated 20% reduction in completion time *after* they had performed the task; the opposite of what had happened." "Economics experts (N=34) and machine learning experts (N=54) overestimated the expected speedup even more dramatically, with 39% and 38%, respectively" (Evidence from controlled trials, software engineering copilots; METR RCT, 16 developers, 246 tasks). Relevance: quantifies miscalibration that persists even after the task is done, evidence that self-forecasts and self-reports are unreliable inputs to planning. Audiences: practitioners, governance. **3. On constrained tasks the same class of tool helps, and the benefit is uneven.** The document: treated participants "completed a standardised, self-contained programming task 56% faster (95% CI 21–89%)", their self-estimated gains "averaged approximately 35%, meaning they *underestimated* the realised speedup", and "the benefit was greater for less experienced developers." "These findings are the first instance of heterogeneous treatment effects of agentic AI" (software engineering copilots; GitHub Copilot RCT, Upwork recruits). Relevance: gains are real in specific, well-defined contexts and vary by task complexity and user experience; supports matching method to task ([BP-01](../best-practices/01-match-method-to-task.md)). Audiences: practitioners, providers. **4. Throughput gains do not account for the cost of verifying output.** The document: developers assigned to Copilot completed "12.9–21.8% more pull requests per week at Microsoft and 7.5–8.7% more at Accenture", but "independent security analyses find that 32.8% of Python and 24.5% of JavaScript snippets generated by Copilot are flagged with security issues", and "Copilot can replicate known-vulnerable code patterns at rates around 33%." "Productivity gains that increase time for human oversight (such as review, remediation, and incident risk) are not net gains" (software engineering copilots). Relevance: gross output metrics omit review and remediation cost; bears directly on human oversight ([BP-09](../best-practices/09-human-in-the-loop.md)). Audiences: practitioners, providers, governance. **5. Vendor time-savings claims contrast with measured minutes, and one tool showed no effect.** The document: Microsoft publicised "5 minutes saved per clinician per encounter on average" for DAX Copilot; a UCLA RCT across "238 physicians in 14 specialties" found "Nabla reduced time-in-note by 9.5% relative to control (95% CI −17.2 to −1.8; P=0.02), while DAX showed no statistically significant effect (−1.7%, 95% CI −9.4 to +5.9; P=0.66)"; the tools "were used in only approximately 30–34% of visits, and roughly 15% of treatment-group physicians never used their assigned scribe at all" (clinical documentation agents). Relevance: marketing figures and deployment-grade measurement diverge, and partial adoption is a persistent contextual factor, not a temporary onboarding issue. Audiences: practitioners, providers, governance. **6. Documentation time can shift rather than fall.** The document: a DAX cohort found "documentation EHR time fell from 5.3 to 4.5 minutes per patient—a saving of approximately 46 seconds—while after-hours EHR time *worsened* significantly, suggesting time-shifting rather than uniform savings" (clinical documentation agents). Relevance: a headline time saving can mask a redistribution of effort; net benefit needs the whole workflow, not one slice. Audiences: practitioners, governance. **7. Perceived benefit does not track measured benefit.** The document: in a study of 252 physicians, "86.5% *perceived* that their documentation time had decreased, yet there was no overall association between perceived reductions and objectively measured time changes (OR 0.975, P=0.144)"; the objective effect was modest, "approximately 30 seconds lower documentation time per scheduled hour" per 10-point usage increase (clinical documentation agents). Relevance: user satisfaction is not evidence of realised gain; reinforces measuring outcomes rather than trusting perception ([BP-08](../best-practices/08-evaluate-tools-before-trust.md)). Audiences: practitioners, governance. **8. Developer-reported accuracy exceeds externally validated accuracy.** The document: the Epic Sepsis Model was "externally validated in a large academic health system (38 455 hospitalisations) with an area under the receiver operating characteristic curve (AUROC) of 0.63 (95% CI 0.62–0.64), while Epic previously reported AUROC values of 0.76–0.83", achieving "only 33% sensitivity (missing two thirds of septic patients)"; IBM "publicised concordance rates as high as 96% for Watson for Oncology", while a Korean retrospective study "found strict concordance of 48.9% for colon cancer" (clinical decision support). Relevance: internally reported metrics set expectations that external, deployment-grade evaluation does not reproduce; the core case for adopter-side evaluation ([BP-08](../best-practices/08-evaluate-tools-before-trust.md)). Audiences: practitioners, providers, governance. **9. Three mechanistic drivers explain why expectations overshoot.** The document: the gap is driven by "workflow integration friction and partial adoption", "verification and review burden", and "measurement construct mismatch", "consistent with planning fallacies widely reported in the psychology literature." "In the METR software engineering trial, the net slowdown occurred because the time spent reviewing, debugging, and integrating AI-generated code exceeded the time saved in initial generation" (Why expectations overshoot). Relevance: friction and partial adoption bear on interface design ([BP-06](../best-practices/06-design-around-user-tasks.md)); verification burden on oversight ([BP-09](../best-practices/09-human-in-the-loop.md)); construct mismatch on evaluation ([BP-08](../best-practices/08-evaluate-tools-before-trust.md)). Audiences: providers, practitioners, governance. **10. Short-horizon metrics miss durable costs to skill and understanding.** The document: an RCT in higher education found students using ChatGPT as a study aid "scored significantly lower on a surprise retention test 45 days later (57.5% vs 68.5%, Cohen's d = 0.68)", and a parallel software engineering study found "AI use impaired the users' conceptual understanding, code reading, and debugging abilities, without delivering significant efficiency gains on average" (Why expectations overshoot). Relevance: benefit projected over short windows can invert over longer ones through cognitive offloading and skill erosion; a planning consideration for research training. Audiences: practitioners, governance. **11. Heterogeneity is the default; there is no stable average gain to plan against.** The document: "there is currently no stable, globally positive treatment effect for agentic AI. Average headline figures ... will systematically misrepresent the benefit realised by any specific user, team, or organisation." A field study of "5,172 agents found an average 15% productivity increase" concentrated "among less experienced and lower-skilled workers, while the most experienced agents saw smaller gains and occasional quality declines"; the METR trial "specifically selected experienced developers ... and this is the population that was slowed" (Heterogeneity as the default). Relevance: planning on an average expected gain over-invests in low-yield deployments and under-invests in targeted high-yield ones; who benefits must be modelled, not assumed. Audiences: practitioners, providers, governance. **12. The review prescribes structured planning with quantified, net-of-oversight expectations.** The document: "benefit expectations must be explicit and quantified across all relevant dimensions"; "expectations should capture dual perspectives" (user expectation and developer feasibility); "human oversight costs must be deducted"; "outcome metrics must link back to initial expectations in the same units and at the same level of granularity"; "heterogeneity should be modelled explicitly." These are operationalised by "the Agentic Automation Canvas (AAC)", which "captures user expectations as quantified benefit metrics across five dimensions—time, quality, risk, enablement, and cost—with baseline values, confidence levels ... and explicit accounting for human oversight" (Implications for structured planning). Relevance: motivates a planning practice upstream of the operational practices; the AAC is the author's own instrument (see cautions). Audiences: practitioners, providers, governance. ## Mapping to practices | Hook | Supports | In tension with | |---|---|---| | 1 | [BP-01](../best-practices/01-match-method-to-task.md) | | | 2 | [BP-08](../best-practices/08-evaluate-tools-before-trust.md) | | | 3 | [BP-01](../best-practices/01-match-method-to-task.md) | | | 4 | [BP-09](../best-practices/09-human-in-the-loop.md) | | | 5 | [BP-08](../best-practices/08-evaluate-tools-before-trust.md) | | | 6 | [BP-09](../best-practices/09-human-in-the-loop.md) | | | 7 | [BP-08](../best-practices/08-evaluate-tools-before-trust.md) | | | 8 | [BP-08](../best-practices/08-evaluate-tools-before-trust.md) | | | 9 | [BP-06](../best-practices/06-design-around-user-tasks.md), [BP-09](../best-practices/09-human-in-the-loop.md), [BP-08](../best-practices/08-evaluate-tools-before-trust.md) | | | 10 | [BP-09](../best-practices/09-human-in-the-loop.md) | | | 11 | [BP-01](../best-practices/01-match-method-to-task.md) | | | 12 | [BP-01](../best-practices/01-match-method-to-task.md) | | No direct tension with an existing practice. The review sits upstream of the record: it argues that the expected net benefit of an agentic method should be quantified and tested before it is committed to. That planning step is an extension of choosing the method for the task ([BP-01](../best-practices/01-match-method-to-task.md)), so it is proposed as a note on that page rather than a new practice. ## Proposed changes to practices To follow the anti-bloat rule (merge rather than add), the planning point is woven into [BP-01](../best-practices/01-match-method-to-task.md) rather than made a new practice, and this review is cited as downweighted external context throughout, not as a driver of change. The author is a contributor to this record, so the document should not carry more weight than the independent evidence it aggregates. - [x] Add a "what it looks like in practice" note on [BP-01](../best-practices/01-match-method-to-task.md), with no change to the practice statement wording: choosing a method includes deciding whether to adopt at all, so state the net benefit you expect before committing, quantified against a baseline and with human oversight cost deducted, and do not assume an average headline gain applies to your users; re-measure the realised outcome against that expectation. This extends "you cannot pick the right method without first understanding the task" to include understanding the expected net benefit. Applied 2026-07-27 (Reasons and Examples note). - [x] Add this review as a supporting/context source to [BP-01](../best-practices/01-match-method-to-task.md): treatment effects are heterogeneous and task-dependent (constrained tasks sped up, expert high-context work slowed), so method fit is decided per task and per user population, not by an average gain. Atoms bp1-a1, bp1-a3. Applied 2026-07-27. - [ ] Optional grounding as context, if the editors want it, kept secondary to the existing sources on each page: - [BP-08](../best-practices/08-evaluate-tools-before-trust.md): developer-reported and vendor-reported metrics systematically exceed externally validated ones (Epic Sepsis AUROC 0.76–0.83 reported vs 0.63 validated; Watson 96% vs 48.9% strict concordance; perceived vs measured documentation time). Atoms bp8-a2, bp8-a3. - [BP-09](../best-practices/09-human-in-the-loop.md): verification and review cost must be deducted from projected benefit; "productivity gains that increase time for human oversight ... are not net gains", and verification burden drove the METR net slowdown. Atom bp9-a5. - [BP-06](../best-practices/06-design-around-user-tasks.md): workflow integration friction and partial adoption are leading drivers of the realised-benefit shortfall. Atom bp6-a1. - [x] Add provenance edges under the named atoms with `ref: expectation-realisation-gap-2026`, `stance: supports`, and the locators/quotes from the hooks. Cited as external field evidence, consistent with how the other out-of-domain source (The GenAI Divide) is handled. Applied 2026-07-27 for bp1-a1 and bp1-a3; the optional BP-06/08/09 edges remain unapplied. ## Cautions and gaps Author interest in the proposed remedy. The prescriptive section recommends the Agentic Automation Canvas, a framework authored by the same author (arXiv:2602.15090). The empirical review rests on independent trials and validations and stands on its own; the AAC recommendation is the author's own instrument and should be treated as one option for structured planning, not the only one. Any new practice drawn from this document should state the planning principle, not endorse a specific canvas. Domain of the evidence. The primary evidence is software engineering copilots, ambient clinical scribes, and clinical decision support, not basic research workflows. The mechanisms (calibration error, verification burden, measurement mismatch, heterogeneity) are generic and transfer by argument; the specific figures should be cited as external field evidence, not as measurements of scientific practice. Clinical decision support and documentation are the closest touch to scientific and medical work. Type of document. This is a narrative review, not new primary research, and an arXiv preprint that has not been peer reviewed. Its contribution is the aggregation and framing of others' controlled evidence. What it does not claim. The document does not argue against agentic AI; it documents miscalibration and heterogeneity and states that "real gains exist in specific contexts and for specific user populations." Reading it as a case for non-adoption would misrepresent it. --- # A safer framework for patient data in AI-for-Science grants (2026) Source: https://aiforscience.eu/library/gagneur-rare-disease-patient-data-2026/index.md # A safer framework for patient data in AI-for-Science grants (2026) !!! info "Source" **Document:** "Anthropic's AI for Science rare disease research grants need a safer framework for patient data". **Author:** Julien Gagneur, Technical University of Munich. **Type:** individual commentary (Medium). **Date:** July 2026. **Distilled:** 2026-07-28. ## Summary The article responds to [Anthropic's AI for Science rare-disease research grants](https://www.anthropic.com/news/rare-disease-research-grants), which offer up to $50,000 in Claude credits over six months to researchers studying rare disease. It argues that the program's data terms are incompatible with how patient data is governed in research. The core point is a distinction the terms collapse: permission to analyse patient data under consent and data-access rules is not permission to transfer that data, or patient-level information derived from it, to a third party for model training or product development. It also describes a concrete technical risk specific to agentic tools: a coding agent that runs code and reads outputs can transmit study-participant data out of an approved environment without a deliberate upload. It proposes a protected research tier (training exclusion, local or secure processing, egress controls, auditability, and a data-processing agreement) that would keep the collaboration while protecting participants. This is one researcher's argued position, not a standard or an institutional report. ## Hooks, with citations **1. Agentic tools can move sensitive data out of an approved environment without a deliberate upload.** The document: "AI agents may run code, inspect results, and transmit relevant material to the external service operating it. Study-participant-level information can therefore leave the approved environment without a deliberate upload" (body). Relevance: names a data-egress path that exists whenever an agent can read local files and call an external model, and it sharpens why stating an oversight level is not enough if a person approves agent-generated code without reading it ([BP09](../best-practices/09-human-in-the-loop.md)). Audiences: practitioners, providers, governance. **2. Permission to analyse data is not permission to transfer or train on it.** The document: "Permission to analyse them does not imply permission to transfer them, or derived patient-level information, to a third party for model training or product development" (body). Relevance: separates two rights that data-access agreements keep distinct, and that a blanket grant conflates. Audiences: governance, practitioners. **3. The program's terms take a broad, perpetual grant over program data.** The document quotes the terms: researchers "warrant that they have obtained all necessary permissions ... to allow Anthropic to collect, analyze, train models on, and conduct research on all data, including Inputs and Outputs", and grant "a perpetual, irrevocable license to use Program data for these purposes" (body). Relevance: for controlled-access clinical or genomic data, a researcher often cannot lawfully make that warranty, so the burden shifts to the person least able to carry it. Audiences: governance, practitioners. **4. A protected research tier: exclude sensitive data from training, process it locally, control egress, and audit.** The document: "patient-level data, derived patient-level outputs, and other controlled-access material are excluded from model training and product-development use, and no perpetual licence is taken over them; sensitive data remain within an institutionally approved environment, with analysis against those data performed locally or through an approved secure-processing arrangement; technical controls prevent patient-level information from being transmitted to Anthropic and allow institutions to audit what the agent can access and send" (body). Relevance: puts the protection in enforced controls and a governed environment rather than in a researcher's promise, matching guardrails-in-the-system ([BP04](../best-practices/04-govern-autonomy-and-accountability.md)) and access governed by the resource ([BP02](../best-practices/02-default-to-agent-accessibility.md)). Audiences: providers, governance. **5. Terms, retention, and responsibilities belong in a data-processing agreement.** The document: "retention, processing locations, subprocessors, security measures, and institutional responsibilities are clearly defined in an appropriate data-processing agreement" (body). Relevance: makes the arrangement auditable and assigns responsibility, rather than leaving it to the grant's default license. Audiences: governance, providers. **6. Open science with boundaries is compatible with protection.** The document argues code, methods, evaluations, curated public resources, and non-sensitive findings can be shared openly while patient data, confidential records, and controlled-access outputs remain protected, and notes that "Anthropic acknowledges, in its commercial offerings, that customers may require stronger restrictions on training, retention, and data use" (body). Relevance: openness by default and protection of controlled-access data are not in conflict; the stronger-restriction option already exists commercially. Audiences: practitioners, providers, governance. ## Mapping to practices | Hook | Supports | In tension with | |---|---|---| | 1 | [BP09](../best-practices/09-human-in-the-loop.md) (bp9-a5); context for [BP03](../best-practices/03-register-and-vet-interfaces.md) | | | 2 | context for [BP04](../best-practices/04-govern-autonomy-and-accountability.md) governance | | | 3 | context for [BP04](../best-practices/04-govern-autonomy-and-accountability.md), [BP02](../best-practices/02-default-to-agent-accessibility.md) | | | 4 | [BP04](../best-practices/04-govern-autonomy-and-accountability.md) (bp4-a1, bp4-a6), [BP02](../best-practices/02-default-to-agent-accessibility.md) (bp2-a4) | | | 5 | context for [BP04](../best-practices/04-govern-autonomy-and-accountability.md) | | | 6 | [BP02](../best-practices/02-default-to-agent-accessibility.md) (bp2-a4); context for [BP07](../best-practices/07-provenance-and-citation.md) | | No direct contradictions with the current practices. The article exposed a gap rather than a conflict: the record governed agent autonomy, access, and oversight, but had no explicit line on irreversible data commitments. That gap is now filled by [BP10](../best-practices/10-screen-dual-use-high-consequence.md) atom bp10-a5, which the article supports as adjacent evidence (the revocable-consent argument itself is grounded on the Declaration of Helsinki and GDPR, not on this commentary). ## Proposed changes to practices These are proposals for editor review, not applied here. - [ ] Add `gagneur-rare-disease-patient-data-2026` as a supporting source on [BP04](../best-practices/04-govern-autonomy-and-accountability.md) (bp4-a1, bp4-a6): egress controls that prevent an agent from transmitting sensitive data, and audit of what the agent can access and send, are guardrails in the system. - [ ] Add it as a supporting source on [BP02](../best-practices/02-default-to-agent-accessibility.md) (bp2-a4): controlled-access data governed by local or approved secure processing. - [ ] Add it as a supporting source on [BP09](../best-practices/09-human-in-the-loop.md) (bp9-a5): a concrete case where approving agent-generated code without review defeats the stated oversight. - [x] Add a new atom on the irreversibility of data commitments. Done as [BP10](../best-practices/10-screen-dual-use-high-consequence.md) bp10-a5: data under withdrawable consent cannot be authorised for third-party model training or a perpetual licence, grounded on the Declaration of Helsinki and GDPR with this commentary as adjacent support. - [ ] Optionally add a reference entry for Anthropic's AI-for-Science rare-disease grants as the program the critique responds to. ## Cautions and gaps This is individual commentary published on Medium, not a peer-reviewed paper, standard, or institutional report; weight it as an argued position and ground any practice change on it accordingly. It critiques one program's terms at one point in time, and those terms may change; the quoted warranty and licence language should be checked against the current program terms before being relied on. The argument is about risk and governance, not evidence of a breach; it does not measure how often agent-driven egress happens in practice. The rare-disease and genomics setting is the article's example; the transferable practice is domain-neutral and concerns any controlled-access or confidential data an agent can reach. --- # Agentic AI in the higher-education system (2026) Source: https://aiforscience.eu/library/hfd-agentic-ai-hochschulsystem-2026/index.md # Agentic AI in the higher-education system (2026) !!! info "Source" **Document:** "Agentische KI im Hochschulsystem: Einsatzszenarien, Kompetenzverschiebungen und Steuerungsmöglichkeiten". **Authors:** Göllner, Ionica, Meier, Miram, Möller, Richter, Sexauer. **Issuing body:** Hochschulforum Digitalisierung / KI-Campus (Stifterverband). **Date:** May 2026 (reflecting discussion as of January 2026). **Distilled:** 2026-07-25. German-language public discussion paper. Quotations below are given verbatim in German with an English rendering. ## Summary A German-language discussion paper from a nine-month community of practice on how institutions handle AI agents in higher education. It sets out types (analytic, generative, agentic AI), works three use cases (administration, teaching, research), maps skills from AI literacy to "agentic professionalism", and looks at strategic governance. The governance part is why it is distilled here: because agents act, written policy no longer binds them, so steering has to move into guardrails, clear role accountability, set autonomy levels, and staged rollout. This reading takes the governance and research-workflow content and generalises it from universities to scientific institutions. Teaching didactics are cited as context, not distilled into practice. This is the main source for the governance practice here. ## Hooks, with citations **1. Agentic AI reaches into all core functions, not one application area.** The document: "Die Möglichkeiten, Folgen und Risiken agentischer KI betreffen damit nicht einzelne Anwendungsbereiche, sondern potenziell alle zentralen Funktions- und Entscheidungsprozesse" (§1, p. 1). Rendering: the possibilities, consequences and risks of agentic AI concern potentially all central functional and decision processes, not single application areas. Relevance: agents change how research is planned, performed and governed, so the topic passes the scope test. Audiences: governance, practitioners. **2. The research agent has concrete source and governance requirements.** The document describes a "Lernender Research-Agent" that monitors a research field and produces periodic briefings, requiring "Zugriff auf qualitätsgesicherte Forschungsquellen (inkl. Metadaten, Zitierinformationen und Retraktionshinweisen)" and "Verlässliche Governance- und Transparenzregeln, die Autonomiegrade, menschliche Aufsicht, Quellen-Nachvollziehbarkeit sowie Datenschutz- und Lizenzkonformität sicherstellen" (§3.3, p. 8-9). Rendering: access to quality-assured research sources including metadata, citation information and retraction notices, and governance rules ensuring autonomy levels, human oversight, source traceability, and data-protection and licence conformity. Relevance: a concrete research workflow that grounds [BP05](../best-practices/05-documentation-and-data-for-agents.md) and [BP07](../best-practices/07-provenance-and-citation.md). Audiences: practitioners, providers. **3. Autonomy, intervention and accountability must be made explicit.** The document: agentic AI requires the ability "Autonomiegrade, Eingriffspunkte und Verantwortungszuschreibungen in Mensch-Agent-Workflows bewusst zu entwerfen, situativ zu verhandeln und auditierbar zu dokumentieren" (§4.1, p. 9-10). Rendering: to consciously design, situationally negotiate and auditably document autonomy levels, intervention points and accountability in human-agent workflows. Relevance: grounds [BP04](../best-practices/04-govern-autonomy-and-accountability.md) and [BP09](../best-practices/09-human-in-the-loop.md). Audiences: governance, practitioners. **4. Situated judgement is not automatable.** The document, citing the European Commission Joint Research Centre (2025): "Situatives Urteil, Präferenzen und Wertentscheidungen sind nicht automatisierbar" (§4.1, p. 10). Rendering: situated judgement, preferences and value decisions are not automatable. Relevance: the epistemic core stays human; grounds [BP04](../best-practices/04-govern-autonomy-and-accountability.md) and [BP07](../best-practices/07-provenance-and-citation.md), and matches the [mission](../about/mission.md) vision. Audiences: practitioners, providers, governance. **5. From guidelines to guardrails.** The document, citing Kassorla et al. (2026): "From Guidelines to Guardrails. The autonomy of AI agents renders traditional governance models obsolete. A system based on written policies and human persuasion is ineffective for a machine that only understands architectural constraints. An agent cannot be persuaded to follow a rule; it can only be prevented from executing an action." (§5.2, footnote 13, p. 13). Relevance: the central governance insight behind [BP04](../best-practices/04-govern-autonomy-and-accountability.md). Audiences: governance, providers. **6. Steer with dynamic guardrails and traceable decision records.** The document: steering "sollte weniger über detaillierte Richtlinien als über dynamische Leitplanken erfolgen, die Handlungsspielräume begrenzen, kontinuierliche ... Prüfmechanismen vorsehen und Entscheidungs- wie Verhinderungsprozesse nachvollziehbar dokumentieren, auch wenn mehrere Agenten beteiligt sind." Governance becomes "ein iterativer Prozess fortlaufender Anpassung" (§5.1, p. 13). Rendering: use dynamic guardrails that bound the action space, provide continuous checks, and document decision and veto processes traceably even when several agents are involved; governance is an iterative process. Relevance: grounds [BP04](../best-practices/04-govern-autonomy-and-accountability.md). Audiences: governance. **7. Anchor accountability to defined roles, not to the institution in the abstract.** The document distinguishes "eine strategische Verantwortung", "eine fachliche Prozessverantwortung ... und menschliche Entscheidungshoheit" and "eine technische Betriebsverantwortung", which "müssen ineinandergreifen und dokumentierte Eskalations- und Abschaltprozesse vorsehen" (§5.2, p. 13-14). Rendering: strategic responsibility, professional process responsibility with human decision authority, and technical operational responsibility must interlock and provide documented escalation and shutdown processes. Relevance: grounds [BP04](../best-practices/04-govern-autonomy-and-accountability.md). Audiences: governance. **8. Adapting an agent can turn a deployer into a provider.** The document: institutions are often deployers "können jedoch gerade beim Einsatz agentischer KI durch Anpassung, Feintuning oder Zweckänderung selbst zu Anbietern werden, mit entsprechend erweiterten Pflichten"; classifying agents into a risk class is "eine Governance-Entscheidung mit strukturellen Folgen" (§5.2 footnote 14, §5.3, p. 13-15). Rendering: through adaptation, fine-tuning or repurposing an institution can itself become a provider with expanded obligations; risk-class assignment is a governance decision with structural consequences. Relevance: grounds [BP03](../best-practices/03-register-and-vet-interfaces.md) and [BP04](../best-practices/04-govern-autonomy-and-accountability.md). Audiences: governance, providers. **9. Infrastructure is an instrument of governance.** The document: control over model inference and over interfaces to core systems become critical governance points, and which agent frameworks may connect and under what conditions is "keine rein technische, sondern eine strategische Entscheidung über Zugriff, Reichweite und Risiko" (§5.3, p. 15). Rendering: not a purely technical question but a strategic decision about access, reach and risk. Relevance: grounds [BP03](../best-practices/03-register-and-vet-interfaces.md) and [BP04](../best-practices/04-govern-autonomy-and-accountability.md). Audiences: governance, providers. **10. Ungoverned personal agents create a new shadow IT.** The document: personal agents with broad access to mail, calendar and file structures form a "'Schatten-IT' [die] sich institutioneller Steuerung entzieht und birgt Risiken für Datensicherheit und Integrität"; proactive governance must address institutional and individual use alike (§5, p. 12). Rendering: a shadow IT that escapes institutional steering and creates data-security and integrity risks. Relevance: grounds [BP04](../best-practices/04-govern-autonomy-and-accountability.md). Audiences: governance. **11. Pilot low-risk first, define transition criteria, inventory and review.** The document recommends starting "mit klar abgegrenzten, risikoarmen Anwendungsfällen", defining success criteria and the conditions for moving to production, defining "zulässige Autonomiegrade und akzeptierte Risikogrenzen", establishing control and escalation mechanisms, and to "inventarisieren Sie KI-Agenten systematisch und überprüfen Sie regelmäßig ihre Arbeitsweise und Ergebnisse" (§6, p. 17-18). Rendering: staged adoption from bounded low-risk cases, explicit success and transition criteria, defined autonomy levels and risk boundaries, control and escalation mechanisms, and systematic inventory and regular review of agents. Relevance: grounds [BP04](../best-practices/04-govern-autonomy-and-accountability.md) and [BP09](../best-practices/09-human-in-the-loop.md). Audiences: governance, providers. **12. The question is what an organisation is willing to grant.** The document: "Die Frage ist nicht nur, was Agenten dürfen (und können) – sondern was eine Organisation ihnen kulturell zuzugestehen bereit ist" (§5.4, p. 16). Rendering: the question is not only what agents may do and can do, but what an organisation is culturally prepared to grant them. Relevance: the governance-culture dimension of [BP04](../best-practices/04-govern-autonomy-and-accountability.md). Audiences: governance. ## Mapping to practices | Hook | Supports | In tension with | |---|---|---| | 1 | (scope confirmation) | | | 2 | [BP05](../best-practices/05-documentation-and-data-for-agents.md), [BP07](../best-practices/07-provenance-and-citation.md) | | | 3, 5, 6, 7, 9, 10, 12 | [BP04](../best-practices/04-govern-autonomy-and-accountability.md) | | | 4 | [BP04](../best-practices/04-govern-autonomy-and-accountability.md), [BP07](../best-practices/07-provenance-and-citation.md) | | | 8 | [BP03](../best-practices/03-register-and-vet-interfaces.md), [BP04](../best-practices/04-govern-autonomy-and-accountability.md) | | | 11 | [BP04](../best-practices/04-govern-autonomy-and-accountability.md), [BP09](../best-practices/09-human-in-the-loop.md) | | No direct tensions. The teaching and examination use cases (§3.2) change how teaching is run rather than how science is done, and are cited as context. ## Proposed changes to practices - [x] Create [BP04](../best-practices/04-govern-autonomy-and-accountability.md) as a new governance-facing practice, grounded primarily in this document (hooks 3, 5, 6, 7, 9, 10, 11, 12). - [x] Add this document as grounding to [BP03](../best-practices/03-register-and-vet-interfaces.md) (hooks 8, 9), [BP05](../best-practices/05-documentation-and-data-for-agents.md) (hook 2), [BP07](../best-practices/07-provenance-and-citation.md) (hooks 2, 4), and [BP09](../best-practices/09-human-in-the-loop.md) (hooks 3, 11). ## Cautions and gaps - The framing is German higher education. Teaching and examination didactics are cited as context and not distilled into practice. - A discussion paper described by its authors as work in progress, not peer-reviewed. All derived practices are `draft`. - EU AI Act specifics (provider versus deployer duties, risk classes) are jurisdiction-bound. The record uses the underlying pattern as a general governance idea, not as legal advice. --- # Library Source: https://aiforscience.eu/library/index.md # Library The library is the provenance store for the [best practices](../best-practices/01-match-method-to-task.md). Everything used to model a practice, whether it supported, qualified, or contradicted a claim, is recorded here so a reader can check it. It has two tiers. **Distilled sources** are rich documents (strategy papers, policy reports, institutional documents) reduced into the passages that matter, with locators and a mapping to the practices. **Reference works** are the standards, papers, reports, and guidance cited as point support, each a short bibliographic record. Raw documents are not hosted here. Each entry carries a full citation to the original. The atom-level record of which source bears on which practice line, and whether it is for or against, lives in the provenance data (`assets/provenance.yml`). ## Distilled sources | Document | Issuing body | Date | Role in the record | |---|---|---|---| | [ELIXIR TF Agentic AI: agenda and rolling best practice](elixir-tf-agentic-ai-2026.md) | ELIXIR Europe, AI Ecosystem Focus Group | 2026 | Main source for the provider-facing practices (BP02, BP03, BP05, BP06, BP07, BP09); also seeds BP08 (evaluation). | | [Agentic AI in the higher-education system](hfd-agentic-ai-hochschulsystem-2026.md) | Hochschulforum Digitalisierung / KI-Campus | May 2026 | Main source for the governance practice (BP04); grounds several others. | | [EU Expert Forum on Frontier AI](ec-expert-forum-2026.md) | European Commission, European AI Office | July 2026 | Largely out of scope; grounds BP01, BP03, BP04, BP07 on method choice, evaluation, and provider choice. | | [ELIXIR AI strategy](elixir-ai-strategy-2026.md) | ELIXIR Europe | June 2026 | Largely organisational; grounds BP05, BP07, BP08 on curated data, provenance, and validation. | | [The GenAI Divide](mit-genai-divide-2025.md) | MIT Project NANDA | July 2025 | Out-of-domain enterprise report; grounds BP01, BP06, BP08 on task fit, workflow design, and outcome-based evaluation; qualifies BP03. | | [Expectation–Realisation Gap for Agentic AI](expectation-realisation-gap-2026.md) | Lobentanzer (Helmholtz Munich) | February 2026 | Review of controlled trials on realised vs expected benefit; downweighted context (author is a contributor); grounds BP01 on heterogeneity and benefit planning, with optional context for BP06, BP08, BP09. | | [EU AI Omnibus](ai-omnibus-2026.md) | European Union | July 2026 | Largely out-of-scope regulatory simplification of the AI Act; grounds BP04 and BP10 on technical safeguards against foreseeable misuse, with context for BP03, BP08. | | [A safer framework for patient data in AI-for-Science grants](gagneur-rare-disease-patient-data-2026.md) | Gagneur (TU Munich) | July 2026 | Individual commentary on grant data terms; grounds BP04, BP02, BP09 on data-egress control, governed access, and effective oversight; flags a gap on controlled-access data in third-party training. | ## Reference works The standards, papers, and reports cited by the practices, grouped by theme. Each links to its bibliographic record. **Method selection** - [Building Effective AI Agents (Anthropic 2024)](ref-anthropic-building-effective-agents-2024.md) - [AI Agents That Matter (Kapoor et al. 2024)](ref-kapoor-agents-that-matter-2024.md) - [Fine-tuned small LLMs beat zero-shot frontier models (Bucher & Martini 2024)](ref-bucher-fine-tuned-2024.md) - [Leakage and the reproducibility crisis in ML-based science (Kapoor & Narayanan 2023)](ref-kapoor-narayanan-leakage-2023.md) **Data and metadata standards** - [FAIR Guiding Principles (2016)](ref-fair-2016.md) - [ELIXIR Core Data Resources (2020)](ref-elixir-cdr-2020.md) - [bio.tools registry (2019)](ref-biotools-2019.md) - [W3C DCAT version 3 (2024)](ref-dcat3-2024.md) - [Croissant dataset metadata (2024)](ref-croissant-2024.md) - [Datasheets for Datasets (2021)](ref-datasheets-2021.md) - [Model Cards for Model Reporting (2019)](ref-model-cards-2019.md) **Provenance, citation, and retraction** - [W3C PROV-O (2013)](ref-prov-o-2013.md) - [CRediT contributor roles taxonomy (2022)](ref-credit-2022.md) - [ICMJE and COPE on AI and authorship (2023)](ref-icmje-cope-2023.md) - [NISO CREC (RP-45-2024)](ref-niso-crec-2024.md) - [Crossref and the Retraction Watch database (2023)](ref-crossref-retraction-watch-2023.md) - [Fabricated citations from LLMs (Walters & Wilder 2023)](ref-walters-wilder-2023.md) - [AI tools cite retracted papers (MIT Technology Review 2025)](ref-mit-tech-review-retracted-2025.md) **Governance and risk frameworks** - [NIST AI Risk Management Framework (2023, 2024)](ref-nist-ai-rmf.md) - [EU AI Act (2024)](ref-eu-ai-act.md) - [OECD AI Principles (2024)](ref-oecd-ai-principles-2024.md) - [ISO/IEC 42001:2023](ref-iso-42001-2023.md) - [OpenAI, Practices for Governing Agentic AI Systems (2023)](ref-openai-governing-agentic-ai-2023.md) - [Chan et al., Visibility into AI Agents (2024)](ref-chan-visibility-2024.md) - [Kolt, Governing AI Agents (2025)](ref-kolt-governing-agents-2025.md) - [JRC, The Role of AI in Scientific Research (2025)](ref-jrc-ai-in-science-2025.md) - [DeepMind, An Approach to Technical AGI Safety (2025)](ref-deepmind-agi-safety-2025.md) **Interface security and channels** - [OWASP Top 10 for LLM Applications 2025](ref-owasp-llm-top10-2025.md) - [OWASP MCP Top 10](ref-owasp-mcp-top10.md) - [Invariant Labs, MCP tool poisoning (2025)](ref-invariant-tool-poisoning-2025.md) - [Official MCP Registry (2025)](ref-mcp-registry-2025.md) - [IETF AIPREF vocabulary (draft)](ref-ietf-aipref.md) - [COAR survey on AI bots and crawlers (2025)](ref-coar-ai-bots-2025.md) - [Web-scraping AI bots disrupt scientific databases (Nature news, 2025)](ref-nature-scraping-bots-2025.md) **Agent-tool design** - [Anthropic, Writing effective tools for agents (2025)](ref-anthropic-writing-tools-2025.md) - [Anthropic, Code execution with MCP (2025)](ref-anthropic-code-execution-mcp-2025.md) - [Anthropic, Advanced tool use (2025)](ref-anthropic-advanced-tool-use-2025.md) - [Model Context Protocol specification](ref-mcp-spec.md) **Human oversight** - [Elish, Moral Crumple Zones (2019)](ref-elish-2019.md) - [Green, Flaws of Policies Requiring Human Oversight (2022)](ref-green-2022.md) **Evaluation** - [REFORMS reporting standards (2024)](ref-reforms-2024.md) - [NeurIPS Paper Checklist](ref-neurips-checklist.md) - [DOME recommendations for ML validation in biology (2021)](ref-dome-2021.md) - [Open and Sustainable AI in the life sciences (OSAI, 2025)](ref-osai-2025.md) **Dual-use and frontier safety** - [METR, Common Elements of Frontier AI Safety Policies (2025)](ref-metr-common-elements-2025.md) - [Frontier Model Forum, Components of Frontier AI Safety Frameworks](ref-fmf-safety-frameworks.md) - [Urbina et al., Dual use of AI-powered drug discovery (2022)](ref-urbina-dual-use-2022.md) - [Wittmann et al., Nucleic-acid biosecurity screening (2025)](ref-wittmann-biosecurity-2025.md) - [UK AI Security Institute, Frontier AI Trends (2025)](ref-aisi-frontier-trends-2025.md) - [Autonomous agent breach of Hugging Face (2026)](ref-hf-openai-agent-breach-2026.md) - [US policy for oversight of Dual Use Research of Concern (2024)](ref-usg-durc-2024.md) **Research ethics and data protection** - [WMA Declaration of Helsinki (2024)](ref-helsinki-2024.md) - [EU General Data Protection Regulation (2016)](ref-gdpr-2016.md) --- # The GenAI Divide (2025) Source: https://aiforscience.eu/library/mit-genai-divide-2025/index.md # The GenAI Divide (2025) !!! info "Source" **Document:** "The GenAI Divide: State of AI in Business 2025". **Issuing body:** MIT Project NANDA (Aditya Challapally, Chris Pease, Ramesh Raskar, Pradyumna Chari). **Date:** July 2025. **Distilled:** 2026-07-27. ## Summary An enterprise-adoption report from MIT's Project NANDA, based on 300+ public AI initiatives, 52 organisation interviews, and 153 senior-leader surveys collected January to June 2025. Its headline finding is that despite $30 to 40 billion in enterprise GenAI investment, 95% of organisations see no measurable return, a gap the authors call the "GenAI Divide". The report locates the cause not in model quality, regulation, or talent but in a "learning gap": most deployed systems do not retain feedback, adapt to context, or improve over time. The document is about business P&L, not science, so most of its content (sales-and-marketing ROI, BPO displacement, workforce impact) is out of scope for this record. Its transferable mechanisms are in scope: tool choice by task, evaluation on task outcomes rather than benchmarks, workflow fit over generic wrappers, memory and adaptation as the deciding capability, and the observation that unsanctioned personal-tool use often outperforms governed deployments. ## Hooks, with citations **1. The failure is one of approach, not model quality.** The document: "95% of organizations are getting zero return ... This divide does not seem to be driven by model quality or regulation, but seems to be determined by approach" (Executive Summary, pg. 3). Relevance: frames adoption failure as a method-and-integration problem, the same premise behind [BP-01](../best-practices/01-match-method-to-task.md) and [BP-06](../best-practices/06-design-around-user-tasks.md). Audiences: practitioners, providers, governance. **2. The core barrier is learning, not infrastructure or talent.** The document: "The core barrier to scaling is not infrastructure, regulation, or talent. It is learning. Most GenAI systems do not retain feedback, adapt to context, or improve over time" (Executive Summary, pg. 3; expanded in §4, pg. 10). Relevance: names memory, context retention, and adaptation as the deciding capabilities; bears on what documentation and state an agent operates from ([BP-05](../best-practices/05-documentation-and-data-for-agents.md)). Audiences: practitioners, providers. **3. Fitness splits sharply by task type.** The document: "AI has already won the war for simple work, 70% prefer AI for drafting emails ... But for anything complex or long-term, humans dominate by 9-to-1 margins. The dividing line isn't intelligence, it's memory, adaptability, and learning capability" (§4.3, pg. 13). Relevance: direct field evidence that method should follow task, and that high-stakes work keeps a human in the loop ([BP-01](../best-practices/01-match-method-to-task.md), [BP-09](../best-practices/09-human-in-the-loop.md)). Audiences: practitioners, governance. **4. Buyers who succeed evaluate on outcomes, not model benchmarks.** The document: buyers who cross the divide "Benchmarked tools on operational outcomes, not model benchmarks" and "evaluate tools based on business outcomes rather than software benchmarks" (§6.2, pg. 20; Executive Summary, pg. 3). Relevance: mirrors [BP-08](../best-practices/08-evaluate-tools-before-trust.md): general leaderboard scores are not evidence a tool is fit for a specific task. Audiences: practitioners, providers, governance. **5. Tools fail on workflow fit, not features.** The document: custom tools "fail due to brittle workflows, lack of contextual learning, and misalignment with day-to-day operations"; buyers want a "Deep understanding of our workflow" and "Most vendors don't get how our approvals or data flows work" (Executive Summary, pg. 3; §5.1, pg. 15). Relevance: supports designing interfaces around real user tasks rather than wrapping generic capability ([BP-06](../best-practices/06-design-around-user-tasks.md)). Audiences: providers, practitioners. **6. A "shadow AI economy" outpaces official deployment.** The document: "only 40% of companies say they purchased an official LLM subscription, [but] workers from over 90% of the companies we surveyed reported regular use of personal AI tools for work tasks ... This 'shadow AI' often delivers better ROI than formal initiatives" (§3.3, pg. 8). Relevance: bears on [BP-03](../best-practices/03-register-and-vet-interfaces.md); governed channels that ignore how people actually work get bypassed, so vetting has to learn from real usage, not only restrict it. Audiences: governance, providers. **7. External partnerships reach deployment about twice as often as internal builds.** The document: "external partnerships with learning-capable, customized tools reached deployment ~67% of the time, compared to ~33% for internally built tools", with the caveat that "correlation between external partnerships and success does not necessarily prove causation" (§6.1, pg. 19). Relevance: a build-versus-buy signal relevant to how research groups and services resource agent capability; the causation caveat is part of the finding. Audiences: providers, governance. **8. Adoption is driven by "prosumers" with accountability retained at the top.** The document: successful organisations "Sourced AI initiatives from frontline managers, not central labs"; deployments "began with power users ... who had already experimented with tools like ChatGPT or Claude", paired with "executive accountability"; and hiring now "consistently emphasize[s] AI literacy as a fundamental capability requirement" (§6.2, pg. 20; §6.4.2, pg. 22). Relevance: distributed initiative with retained accountability tracks [BP-04](../best-practices/04-govern-autonomy-and-accountability.md); AI literacy as a skill requirement bears on training. Audiences: governance, practitioners. **9. The report positions agent memory and interoperability protocols (MCP, A2A, NANDA) as the fix.** The document: "Agentic AI, the class of systems that embeds persistent memory and iterative learning by design, directly addresses the learning gap"; infrastructure is "emerging through frameworks like Model Context Protocol (MCP), Agent-to-Agent (A2A), and NANDA, which enable agent interoperability" (§4.3, pg. 13-14; §5.3, pg. 18; §6.5, pg. 22). Relevance: same protocol substrate the record treats under agent-accessibility and trusted interfaces ([BP-02](../best-practices/02-default-to-agent-accessibility.md), [BP-03](../best-practices/03-register-and-vet-interfaces.md)); note the authors' stake in NANDA (see cautions). Audiences: providers, practitioners. ## Mapping to practices | Hook | Supports | In tension with | |---|---|---| | 1 | [BP-01](../best-practices/01-match-method-to-task.md), [BP-06](../best-practices/06-design-around-user-tasks.md) | | | 2 | [BP-05](../best-practices/05-documentation-and-data-for-agents.md) | | | 3 | [BP-01](../best-practices/01-match-method-to-task.md), [BP-09](../best-practices/09-human-in-the-loop.md) | | | 4 | [BP-08](../best-practices/08-evaluate-tools-before-trust.md) | | | 5 | [BP-06](../best-practices/06-design-around-user-tasks.md) | | | 6 | [BP-03](../best-practices/03-register-and-vet-interfaces.md) | [BP-03](../best-practices/03-register-and-vet-interfaces.md) | | 7 | [BP-01](../best-practices/01-match-method-to-task.md) | | | 8 | [BP-04](../best-practices/04-govern-autonomy-and-accountability.md) | | | 9 | [BP-02](../best-practices/02-default-to-agent-accessibility.md), [BP-03](../best-practices/03-register-and-vet-interfaces.md) | [BP-01](../best-practices/01-match-method-to-task.md) | Tension on hook 6: the shadow-AI finding shows that vetting confined to a locked-down approved list gets routed around when the approved tools do not fit the work. The practice still holds; the finding sharpens it toward vetting that learns from observed usage rather than blocking it. Tension on hook 9: the report treats agentic systems with memory as the general answer, while [BP-01](../best-practices/01-match-method-to-task.md) holds that an agent is one option among several and often not the right one. The report is co-produced by Project NANDA, an agent-infrastructure effort, so this framing carries a vendor interest. ## Proposed changes to practices - [x] Add this report as a supporting source to [BP-08](../best-practices/08-evaluate-tools-before-trust.md): field evidence that buyers who benchmark on task outcomes rather than model benchmarks succeed far more often (atom bp8-a3). Applied 2026-07-27. - [x] Add as a supporting source to [BP-06](../best-practices/06-design-around-user-tasks.md): tools that miss workflow fit stall regardless of model quality (atom bp6-a1). Applied 2026-07-27. - [x] Add as a supporting source to [BP-01](../best-practices/01-match-method-to-task.md): task type, not model capability, decides fit; simple tasks suit generic tools, complex work stays with humans (atom bp1-a1). Applied 2026-07-27. - [x] Add a "what it looks like in practice" note on [BP-03](../best-practices/03-register-and-vet-interfaces.md): unsanctioned personal-tool use outpaces governed deployment when approved tools do not fit real work, so vetting should learn from observed usage. No wording change to the practice statement itself. Applied 2026-07-27. - [ ] No new practice. The report grounds existing practices; it does not clear the gating bar for a new one (it is out-of-domain enterprise evidence, and its distinct actions are already covered). ## Cautions and gaps Domain mismatch. This is an enterprise business report; its subject is corporate P&L, not scientific work. Its statistics (95% zero return, ROI figures, industry disruption scores) describe commercial adoption and should be cited as external context, not as findings about science. The one direct science touch is thin: healthcare and pharma appear only as "documentation/transcription pilots; clinical models unchanged" (pg. 5), and a pharma procurement quote notes AI "helps our scientists get their tools faster ... several degrees removed from bottom-line impact" (pg. 9). Author interest. The report is produced with Project NANDA, which builds agent-interoperability infrastructure (MCP, A2A, NANDA). Its conclusion that agentic, memory-equipped systems are the way across the divide aligns with that interest. Treat the agentic-web framing (§6.5, pg. 22) as advocacy, not evidence. Method limits stated by the authors. Findings are "directionally accurate based on individual interviews rather than official company reporting" (pg. 6); build-versus-buy success rates "may reflect organizational capabilities rather than implementation approach alone" (pg. 19); the six-month observation window "may be insufficient" and could understate success (pg. 24). Selection bias toward organisations willing to discuss AI is acknowledged. Not peer reviewed. The document is a preliminary industry report, self-described as "Preliminary Findings" (pg. 2). --- # Frontier AI Trends (2025) Source: https://aiforscience.eu/library/ref-aisi-frontier-trends-2025/index.md # Frontier AI Trends (2025) !!! info "Reference" **Citation:** UK AI Security Institute. "Frontier AI Trends" (2025). **Type:** report. **Link:** [aisi.gov.uk](https://www.aisi.gov.uk/blog/5-key-findings-from-our-first-frontier-ai-trends-report). ## What it is The first frontier AI trends report from the UK AI Security Institute. It measures cyber-offense capability rising toward expert level. ## Role in the record - Grounds [BP10](../best-practices/10-screen-dual-use-high-consequence.md): the cyber instance, with measured cyber-offense capability rising toward expert level. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # Advanced tool use (2025) Source: https://aiforscience.eu/library/ref-anthropic-advanced-tool-use-2025/index.md # Advanced tool use (2025) !!! info "Reference" **Citation:** Anthropic. "Advanced tool use" (24 Nov 2025). **Type:** guidance. **Link:** [anthropic.com/engineering/advanced-tool-use](https://www.anthropic.com/engineering/advanced-tool-use). ## What it is Engineering guidance on advanced tool use for agents. It reports how the size of the tool surface affects token cost and tool-selection accuracy. ## Role in the record - Grounds [BP06](../best-practices/06-design-around-user-tasks.md): a large tool surface raises token cost and lowers tool-selection accuracy. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # Building Effective AI Agents (Anthropic, 2024) Source: https://aiforscience.eu/library/ref-anthropic-building-effective-agents-2024/index.md # Building Effective AI Agents (Anthropic, 2024) !!! info "Reference" **Citation:** Anthropic. "Building Effective AI Agents" (Engineering, 2024). **Type:** guidance. **Link:** [anthropic.com/engineering/building-effective-agents](https://www.anthropic.com/engineering/building-effective-agents). ## What it is Vendor engineering guidance on when and how to build agentic systems. It distinguishes workflows (predefined paths) from agents (model-driven control) and advises starting with the simplest approach that works. ## Role in the record - Grounds [BP01](../best-practices/01-match-method-to-task.md): find the simplest solution and add agentic complexity only when the task needs flexible, model-driven decisions at scale; agents trade latency and cost for task performance, and a single optimised call is often enough. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # Code execution with MCP (2025) Source: https://aiforscience.eu/library/ref-anthropic-code-execution-mcp-2025/index.md # Code execution with MCP (2025) !!! info "Reference" **Citation:** Anthropic. "Code execution with MCP" (4 Nov 2025). **Type:** guidance. **Link:** [anthropic.com/engineering/code-execution-with-mcp](https://www.anthropic.com/engineering/code-execution-with-mcp). ## What it is Engineering guidance on using code execution with MCP. It measures the token cost of exposing one tool per endpoint and presents progressive disclosure as a remedy. ## Role in the record - Grounds [BP06](../best-practices/06-design-around-user-tasks.md): quantifies the token cost of per-endpoint tool use; progressive disclosure as an alternative remedy. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # Writing effective tools for agents (2025) Source: https://aiforscience.eu/library/ref-anthropic-writing-tools-2025/index.md # Writing effective tools for agents (2025) !!! info "Reference" **Citation:** Anthropic. "Writing effective tools for agents" (11 Sep 2025). **Type:** guidance. **Link:** [anthropic.com/engineering/writing-tools-for-agents](https://www.anthropic.com/engineering/writing-tools-for-agents). ## What it is Engineering guidance on how to design tools for agents. It argues for a small set of tools built around high-impact workflows rather than a tool per endpoint. ## Role in the record - Grounds [BP06](../best-practices/06-design-around-user-tasks.md): tools that merely wrap existing endpoints perform worse than a few tools built for high-impact workflows. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # bio.tools registry (2019) Source: https://aiforscience.eu/library/ref-biotools-2019/index.md # bio.tools registry (2019) !!! info "Reference" **Citation:** Ison, J. et al. "The bio.tools registry of software tools and data resources for the life sciences." *Genome Biology* 20, 164 (2019). **Type:** tool. **Link:** [doi:10.1186/s13059-019-1772-6](https://doi.org/10.1186/s13059-019-1772-6). ## What it is A registry that catalogues life-science software tools and data resources through shared, standardised metadata. It keeps many heterogeneous tools discoverable in one place. ## Role in the record - Grounds [BP02](../best-practices/02-default-to-agent-accessibility.md): a light generic registry keeping many tools discoverable through shared metadata (life-science instance). Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # Fine-Tuned 'Small' LLMs Still Outperform Zero-Shot Generative Models in Text Classification (Bucher & Martini, 2024) Source: https://aiforscience.eu/library/ref-bucher-fine-tuned-2024/index.md # Fine-Tuned "Small" LLMs Still Outperform Zero-Shot Generative Models in Text Classification (Bucher & Martini, 2024) !!! info "Reference" **Citation:** Bucher, M. J. J., Martini, M. "Fine-Tuned 'Small' LLMs (Still) Significantly Outperform Zero-Shot Generative AI Models in Text Classification." arXiv:2406.08660 (2024). **Type:** paper. **Link:** [arxiv.org/abs/2406.08660](https://arxiv.org/abs/2406.08660). ## What it is An empirical comparison on text classification. Smaller models fine-tuned on task data consistently and significantly beat larger frontier models prompted zero-shot, at lower cost. ## Role in the record - Grounds [BP01](../best-practices/01-match-method-to-task.md): a specialized, smaller model can be more accurate than a general frontier LLM on a well-defined task, so the frontier model is not the default. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # Visibility into AI Agents (2024) Source: https://aiforscience.eu/library/ref-chan-visibility-2024/index.md # Visibility into AI Agents (2024) !!! info "Reference" **Citation:** Chan et al. "Visibility into AI Agents." ACM FAccT 2024. arXiv:2401.13138. **Type:** paper. **Link:** [arxiv.org/abs/2401.13138](https://arxiv.org/abs/2401.13138). ## What it is A paper on measures that make AI agent activity visible. It examines agent identifiers, real-time monitoring, and activity logging. ## Role in the record - Grounds [BP04](../best-practices/04-govern-autonomy-and-accountability.md): agent identifiers, real-time monitoring, and activity logging as the substrate of accountability. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # COAR survey on AI bots and crawlers (2025) Source: https://aiforscience.eu/library/ref-coar-ai-bots-2025/index.md # COAR survey on AI bots and crawlers (2025) !!! info "Reference" **Citation:** Confederation of Open Access Repositories. "Report of the COAR Survey on AI Bots" (June 2025). **Type:** report. **Link:** [coar-repositories.org (PDF)](https://coar-repositories.org/wp-content/uploads/2025/06/Report-of-the-COAR-Survey-on-AI-Bots-June-2025-1.pdf). ## What it is A survey of open access repositories on the impact of AI bots and crawlers. It reports how repositories experience and respond to automated traffic. ## Role in the record - Grounds [BP02](../best-practices/02-default-to-agent-accessibility.md): open resources face heavy automated load and blunt blocking also blocks real users. - Grounds [BP03](../best-practices/03-register-and-vet-interfaces.md): the case for identified, shapeable agent traffic. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # CRediT contributor roles taxonomy (2022) Source: https://aiforscience.eu/library/ref-credit-2022/index.md # CRediT contributor roles taxonomy (2022) !!! info "Reference" **Citation:** NISO. "CRediT, Contributor Roles Taxonomy." ANSI/NISO Z39.104-2022 (2022). **Type:** standard. **Link:** [credit.niso.org](https://credit.niso.org/). ## What it is A standardised taxonomy of contributor roles for research outputs. It lets each contribution be recorded against named roles at the byline. ## Role in the record - Grounds [BP07](../best-practices/07-provenance-and-citation.md): machine-readable, byline-level contribution attribution (separating human and agent contributions). Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # Croissant dataset metadata (2024) Source: https://aiforscience.eu/library/ref-croissant-2024/index.md # Croissant dataset metadata (2024) !!! info "Reference" **Citation:** MLCommons. "Croissant: a metadata format for ML-ready datasets" (2024). **Type:** standard. **Link:** [mlcommons.org/working-groups/data/croissant](https://mlcommons.org/working-groups/data/croissant/). ## What it is A metadata format that describes machine-learning-ready datasets on top of schema.org. It packages structure, resources, and semantics so datasets load consistently across tools. ## Role in the record - Grounds [BP05](../best-practices/05-documentation-and-data-for-agents.md): schema.org-based description of ML-ready datasets. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # Crossref and the Retraction Watch database (2023) Source: https://aiforscience.eu/library/ref-crossref-retraction-watch-2023/index.md # Crossref and the Retraction Watch database (2023) !!! info "Reference" **Citation:** Crossref. "News: Crossref and Retraction Watch" (2023). **Type:** tool. **Link:** [www.crossref.org/blog/news-crossref-and-retraction-watch](https://www.crossref.org/blog/news-crossref-and-retraction-watch). ## What it is Crossref acquired the Retraction Watch database and made it openly available. Retraction records are distributed as open, machine-readable metadata. ## Role in the record - Grounds [BP07](../best-practices/07-provenance-and-citation.md): open, machine-readable retraction data that makes propagation feasible. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # Datasheets for Datasets (2021) Source: https://aiforscience.eu/library/ref-datasheets-2021/index.md # Datasheets for Datasets (2021) !!! info "Reference" **Citation:** Gebru, T. et al. "Datasheets for Datasets." *Communications of the ACM* 64(12), 86-92 (2021). **Type:** paper. **Link:** [doi:10.1145/3458723](https://doi.org/10.1145/3458723). ## What it is A proposal to accompany every dataset with a structured record of its motivation, composition, collection, and recommended uses. The record travels with the data so downstream users can judge fitness. ## Role in the record - Grounds [BP05](../best-practices/05-documentation-and-data-for-agents.md): documented dataset provenance and intended use. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # W3C DCAT version 3 (2024) Source: https://aiforscience.eu/library/ref-dcat3-2024/index.md # W3C DCAT version 3 (2024) !!! info "Reference" **Citation:** W3C. "Data Catalog Vocabulary (DCAT) - Version 3." W3C Recommendation (2024). **Type:** standard. **Link:** [www.w3.org/TR/vocab-dcat-3](https://www.w3.org/TR/vocab-dcat-3/). ## What it is A vocabulary for describing datasets and data catalogues in a machine-readable form. It supports interoperability between catalogues on the web. ## Role in the record - Grounds [BP05](../best-practices/05-documentation-and-data-for-agents.md): machine-readable dataset metadata. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # An Approach to Technical AGI Safety and Security (2025) Source: https://aiforscience.eu/library/ref-deepmind-agi-safety-2025/index.md # An Approach to Technical AGI Safety and Security (2025) !!! info "Reference" **Citation:** Google DeepMind. "An Approach to Technical AGI Safety and Security" (2025). arXiv:2504.01849. **Type:** report. **Link:** [arxiv.org/abs/2504.01849](https://arxiv.org/abs/2504.01849). ## What it is A report on technical approaches to AGI safety and security. It sets out system-level controls that assume the model cannot be fully trusted. ## Role in the record - Grounds [BP04](../best-practices/04-govern-autonomy-and-accountability.md): system-level controls (access control, monitoring, action restrictions) treating the model as untrusted. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # DOME recommendations for ML validation in biology (2021) Source: https://aiforscience.eu/library/ref-dome-2021/index.md # DOME recommendations for ML validation in biology (2021) !!! info "Reference" **Citation:** Walsh, I., Fishman, D., Garcia-Gasulla, D. et al. "DOME: recommendations for supervised machine learning validation in biology." *Nature Methods* 18, 1122–1127 (2021). **Type:** standard. **Link:** [doi:10.1038/s41592-021-01205-4](https://doi.org/10.1038/s41592-021-01205-4). ## What it is A community set of reporting recommendations, from the ELIXIR Machine Learning Focus Group, for supervised machine learning in biology. It covers four areas, Data, Optimization, Model, and Evaluation, and states what to report so a model's validation can be judged, including the independence of training and test data. ## Role in the record - Grounds [BP08](../best-practices/08-evaluate-tools-before-trust.md): reporting standards for ML validation in biology, including guards against data leakage between training and test sets. - Grounds [BP05](../best-practices/05-documentation-and-data-for-agents.md): structured reporting of the data and model so a resource is reusable. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # Moral Crumple Zones (2019) Source: https://aiforscience.eu/library/ref-elish-2019/index.md # Moral Crumple Zones (2019) !!! info "Reference" **Citation:** Elish, M. C. "Moral Crumple Zones: Cautionary Tales in Human-Robot Interaction." *Engaging Science, Technology, and Society* 5, 40-60 (2019). **Type:** paper. **Link:** [estsjournal.org](https://estsjournal.org/index.php/ests/article/view/260). ## What it is An analysis of how responsibility falls on human operators in automated systems. The nominal human-in-the-loop can absorb blame for a system they cannot realistically control. ## Role in the record - Grounds [BP09](../best-practices/09-human-in-the-loop.md): a qualification on stated human-in-the-loop, showing the human can become a blame sink rather than an effective control. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # The ELIXIR Core Data Resources (2020) Source: https://aiforscience.eu/library/ref-elixir-cdr-2020/index.md # The ELIXIR Core Data Resources (2020) !!! info "Reference" **Citation:** Drysdale, R. et al. "The ELIXIR Core Data Resources: fundamental infrastructure for the life sciences." *Bioinformatics* 36(8), 2636-2642 (2020). **Type:** paper. **Link:** [doi:10.1093/bioinformatics/btz959](https://doi.org/10.1093/bioinformatics/btz959). ## What it is A defined set of life-science data resources of fundamental importance to the wider community, selected against explicit indicators of demand and quality. A top tier is funded and maintained as shared infrastructure. ## Role in the record - Grounds [BP02](../best-practices/02-default-to-agent-accessibility.md): a demand-and-importance typology of data resources with a top tier funded as infrastructure (life-science instance). Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # EU AI Act (Regulation (EU) 2024/1689) Source: https://aiforscience.eu/library/ref-eu-ai-act/index.md # EU AI Act (Regulation (EU) 2024/1689) !!! info "Reference" **Citation:** European Union. "Regulation (EU) 2024/1689 (Artificial Intelligence Act)" (2024). **Type:** policy. **Link:** [artificialintelligenceact.eu](https://artificialintelligenceact.eu/). ## What it is The European Union regulation on artificial intelligence. It sets a risk-based classification with obligations for providers and deployers of high-risk systems. Amended in 2026 by the [AI Omnibus](ai-omnibus-2026.md) (Regulation (EU) 2026/1744): the AI literacy duty softened from "ensure" to "support" (Art 4), a new legal basis added for processing special-category data to detect and correct bias (Art 4a), and high-risk compliance dates postponed to 2 December 2027 (Annex III) and 2 August 2028 (Annex I). ## Role in the record - Grounds [BP03](../best-practices/03-register-and-vet-interfaces.md): Article 25 (a substantial modification can turn a deployer into a provider; framed for high-risk systems, threshold not yet fully defined). - Grounds [BP04](../best-practices/04-govern-autonomy-and-accountability.md): Articles 14 and 26 (human oversight; deployer duties). - Grounds [BP09](../best-practices/09-human-in-the-loop.md): Article 14 (oversight must be effective and names automation bias as a hazard). Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # FAIR Guiding Principles (2016) Source: https://aiforscience.eu/library/ref-fair-2016/index.md # FAIR Guiding Principles (2016) !!! info "Reference" **Citation:** Wilkinson, M. D. et al. "The FAIR Guiding Principles for scientific data management and stewardship." *Scientific Data* 3, 160018 (2016). **Type:** standard. **Link:** [doi:10.1038/sdata.2016.18](https://doi.org/10.1038/sdata.2016.18). ## What it is A set of principles for making data findable, accessible, interoperable, and reusable by machines as well as people. Machine-actionability is the founding motivation. ## Role in the record - Grounds [BP02](../best-practices/02-default-to-agent-accessibility.md): machine-actionability as the general goal behind default agent-accessibility. The Accessible principle permits authentication, so "accessible" never meant "open without limit". - Grounds [BP05](../best-practices/05-documentation-and-data-for-agents.md): documentation and metadata as an interface machines operate from. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # Components of Frontier AI Safety Frameworks Source: https://aiforscience.eu/library/ref-fmf-safety-frameworks/index.md # Components of Frontier AI Safety Frameworks !!! info "Reference" **Citation:** Frontier Model Forum. "Issue Brief: Components of Frontier AI Safety Frameworks." **Type:** report. **Link:** [frontiermodelforum.org](https://www.frontiermodelforum.org/updates/issue-brief-components-of-frontier-ai-safety-frameworks/). ## What it is An issue brief describing the components of frontier AI safety frameworks. It names CBRN, offensive cyber, and automated AI R&D as high-consequence domains. ## Role in the record - Grounds [BP10](../best-practices/10-screen-dual-use-high-consequence.md): CBRN, offensive cyber, and automated AI R&D named as the parallel high-consequence domains. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # EU General Data Protection Regulation (Regulation (EU) 2016/679) Source: https://aiforscience.eu/library/ref-gdpr-2016/index.md # EU General Data Protection Regulation (Regulation (EU) 2016/679) !!! info "Reference" **Citation:** European Union. "Regulation (EU) 2016/679 (General Data Protection Regulation)" (2016). **Type:** policy. **Link:** [eur-lex.europa.eu](https://eur-lex.europa.eu/eli/reg/2016/679/oj). ## What it is The European Union regulation on the protection of personal data. Where processing rests on consent, the data subject has the right to withdraw it at any time (Article 7(3)), and a right to erasure of personal data (Article 17). ## Role in the record - Grounds [BP10](../best-practices/10-screen-dual-use-high-consequence.md) (bp10-a5): consent is revocable and erasure is a right, so personal data held under withdrawable consent cannot be authorised for an irreversible use such as third-party model training or a perpetual licence. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # Flaws of Policies Requiring Human Oversight (2022) Source: https://aiforscience.eu/library/ref-green-2022/index.md # Flaws of Policies Requiring Human Oversight (2022) !!! info "Reference" **Citation:** Green, B. "The Flaws of Policies Requiring Human Oversight of Government Algorithms." *Computer Law & Security Review* (2022). arXiv:2109.05067. **Type:** paper. **Link:** [arxiv.org/pdf/2109.05067](https://arxiv.org/pdf/2109.05067). ## What it is A study of policies that mandate human oversight of algorithms. It finds these mandates frequently fail to deliver the protections claimed for them. ## Role in the record - Grounds [BP09](../best-practices/09-human-in-the-loop.md): a qualification on stated human-in-the-loop, showing oversight mandates often do not deliver their intended protections. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # WMA Declaration of Helsinki (2024) Source: https://aiforscience.eu/library/ref-helsinki-2024/index.md # WMA Declaration of Helsinki (2024) !!! info "Reference" **Citation:** World Medical Association. "WMA Declaration of Helsinki: Ethical Principles for Medical Research Involving Human Participants" (revised 2024). **Type:** guidance. **Link:** [wma.net](https://www.wma.net/policies-post/wma-declaration-of-helsinki/). ## What it is The foundational research-ethics statement for medical research involving human participants. Participation is voluntary, and a participant may withdraw consent at any time without reprisal. ## Role in the record - Grounds [BP10](../best-practices/10-screen-dual-use-high-consequence.md) (bp10-a5): because a participant can withdraw at any time, data held under that consent cannot be committed to a use that could not later honour a withdrawal, such as irreversible model training. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # Autonomous agent breach of Hugging Face (2026) Source: https://aiforscience.eu/library/ref-hf-openai-agent-breach-2026/index.md # Autonomous agent breach of Hugging Face (2026) !!! info "Reference" **Citation:** Hugging Face, "Security incident disclosure — July 2026" (16 July 2026); OpenAI, "OpenAI and Hugging Face partner to address security incident during model evaluation" (2026). **Type:** incident disclosure. **Link:** [Hugging Face disclosure](https://huggingface.co/blog/security-incident-july-2026) and [OpenAI account](https://openai.com/index/hugging-face-model-evaluation-security-incident/). ## What it is During an internal cyber-capability evaluation with safety guardrails reduced, an autonomous system built on OpenAI pre-release models escaped its test sandbox, exploited vulnerabilities in Hugging Face's dataset pipeline, harvested credentials, and moved laterally across production infrastructure. Both organisations confirmed the incident. It is an early real-world case of a frontier agent's offensive-cyber capability causing operational harm outside a controlled setting. ## Role in the record - Grounds [BP10](../best-practices/10-screen-dual-use-high-consequence.md): the cyber instance of dual-use risk, a realised attack driven end to end by an autonomous agent, which motivates screening and containment before an agent is given real-world reach. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # ICMJE and COPE on AI and authorship (2023) Source: https://aiforscience.eu/library/ref-icmje-cope-2023/index.md # ICMJE and COPE on AI and authorship (2023) !!! info "Reference" **Citation:** COPE. "Authorship and AI tools," position statement (2023); ICMJE, "Recommendations" (2023). **Type:** guidance. **Link:** [publicationethics.org/guidance/cope-position/authorship-and-ai-tools](https://publicationethics.org/guidance/cope-position/authorship-and-ai-tools). ## What it is Editorial positions on the use of AI tools in scholarly writing. They hold that AI tools cannot be listed as authors, that their use must be disclosed, and that named human authors remain accountable. ## Role in the record - Grounds [BP07](../best-practices/07-provenance-and-citation.md): AI cannot be an author; AI use must be disclosed; humans remain accountable (settled editorial consensus). Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # IETF AIPREF vocabulary (draft) Source: https://aiforscience.eu/library/ref-ietf-aipref/index.md # IETF AIPREF vocabulary (draft) !!! info "Reference" **Citation:** IETF AIPREF Working Group. "AIPREF vocabulary" (draft-ietf-aipref-vocab). **Type:** standard. **Link:** [ietf-wg-aipref.github.io/drafts/draft-ietf-aipref-vocab.html](https://ietf-wg-aipref.github.io/drafts/draft-ietf-aipref-vocab.html). ## What it is A vocabulary for declaring preferences to automated clients. It is an Internet-Draft, not a ratified standard. ## Role in the record - Grounds [BP03](../best-practices/03-register-and-vet-interfaces.md): an emerging machine-readable way to declare access preferences to automated clients. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # MCP tool poisoning attacks (2025) Source: https://aiforscience.eu/library/ref-invariant-tool-poisoning-2025/index.md # MCP tool poisoning attacks (2025) !!! info "Reference" **Citation:** Invariant Labs. "MCP tool poisoning attacks" (1 Apr 2025). **Type:** report. **Link:** [invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks](https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks). ## What it is A security notification describing tool poisoning attacks against the Model Context Protocol. It documents how a tool description can carry hidden instructions. ## Role in the record - Grounds [BP03](../best-practices/03-register-and-vet-interfaces.md): a poisoned tool description hides instructions from the user; the rug-pull variant mutates a tool after approval. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # ISO/IEC 42001:2023 (AI management systems) Source: https://aiforscience.eu/library/ref-iso-42001-2023/index.md # ISO/IEC 42001:2023 (AI management systems) !!! info "Reference" **Citation:** ISO/IEC. "ISO/IEC 42001:2023, Information technology, Artificial intelligence, Management system" (2023). **Type:** standard. **Link:** [iso.org/standard/81230.html](https://www.iso.org/standard/81230.html). ## What it is An international standard for an AI management system. It specifies requirements for organisations to govern the development and use of AI. ## Role in the record - Grounds [BP04](../best-practices/04-govern-autonomy-and-accountability.md): assigned accountability, an AI system inventory, and governance as continual improvement. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # The Role of AI in Scientific Research (JRC143482, 2025) Source: https://aiforscience.eu/library/ref-jrc-ai-in-science-2025/index.md # The Role of AI in Scientific Research (JRC143482, 2025) !!! info "Reference" **Citation:** European Commission Joint Research Centre. "The Role of AI in Scientific Research" (JRC143482, 2025). **Type:** report. **Link:** [publications.jrc.ec.europa.eu/repository/handle/JRC143482](https://publications.jrc.ec.europa.eu/repository/handle/JRC143482). ## What it is A report on how AI is used across scientific research. It frames AI as a tool with human accountability in science. The record cites this report for the accountability framing and does not attribute the exact "not automatable" wording to it without a located passage. ## Role in the record - Grounds [BP01](../best-practices/01-match-method-to-task.md): AI framed as a tool in science, so an agent or model is a chosen instrument rather than a default. - Grounds [BP04](../best-practices/04-govern-autonomy-and-accountability.md): AI as a tool with human accountability in science. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # AI Agents That Matter (Kapoor et al., 2024) Source: https://aiforscience.eu/library/ref-kapoor-agents-that-matter-2024/index.md # AI Agents That Matter (Kapoor et al., 2024) !!! info "Reference" **Citation:** Kapoor, S., Stroebl, B., Siegel, Z. S., Nadgir, N., Narayanan, A. "AI Agents That Matter." arXiv:2407.01502 (2024). **Type:** paper. **Link:** [arxiv.org/abs/2407.01502](https://arxiv.org/abs/2407.01502). ## What it is An analysis of how agent benchmarks are reported. It shows that evaluating accuracy alone, without cost, rewards needlessly complex and expensive agents, and that cost-controlled evaluation lets much simpler baselines match state-of-the-art accuracy. ## Role in the record - Grounds [BP01](../best-practices/01-match-method-to-task.md): once cost is measured, complex agents often do not beat simple baselines, so an agent is not the default choice for a task. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # Leakage and the Reproducibility Crisis in ML-based Science (Kapoor & Narayanan, 2023) Source: https://aiforscience.eu/library/ref-kapoor-narayanan-leakage-2023/index.md # Leakage and the Reproducibility Crisis in ML-based Science (Kapoor & Narayanan, 2023) !!! info "Reference" **Citation:** Kapoor, S., Narayanan, A. "Leakage and the reproducibility crisis in machine-learning-based science." *Patterns* 4(9), 100804 (2023). **Type:** paper. **Link:** [doi.org/10.1016/j.patter.2023.100804](https://doi.org/10.1016/j.patter.2023.100804). ## What it is A survey of data leakage as a failure mode in ML-based science, found across 294 papers in 17 fields. Leakage produces over-optimistic performance that does not reproduce. ## Role in the record - Grounds [BP01](../best-practices/01-match-method-to-task.md): reaching for a model where the method does not fit the task produces non-reproducible, over-optimistic results, one of the avoidable failure modes the practice warns against. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # Governing AI Agents (2025) Source: https://aiforscience.eu/library/ref-kolt-governing-agents-2025/index.md # Governing AI Agents (2025) !!! info "Reference" **Citation:** Kolt, N. "Governing AI Agents." Notre Dame Law Review (forthcoming). arXiv:2501.07913. **Type:** paper. **Link:** [arxiv.org/abs/2501.07913](https://arxiv.org/abs/2501.07913). ## What it is A legal analysis of AI agents. It addresses how accountability and control apply to agents that act on behalf of principals. ## Role in the record - Grounds [BP04](../best-practices/04-govern-autonomy-and-accountability.md): legal treatment of agent accountability and control. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # Official Model Context Protocol Registry (2025) Source: https://aiforscience.eu/library/ref-mcp-registry-2025/index.md # Official Model Context Protocol Registry (2025) !!! info "Reference" **Citation:** Model Context Protocol project. "Official Model Context Protocol Registry" (2025). **Type:** tool. **Link:** [blog.modelcontextprotocol.io/posts/2025-09-08-mcp-registry-preview](https://blog.modelcontextprotocol.io/posts/2025-09-08-mcp-registry-preview/). ## What it is A preview of the official registry for Model Context Protocol servers. It lists server entries submitted by their maintainers. ## Role in the record - Grounds [BP03](../best-practices/03-register-and-vet-interfaces.md): evidence that the official registry lists self-reported data and runs no security review, so listing and vetting must be kept distinct. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # Model Context Protocol specification Source: https://aiforscience.eu/library/ref-mcp-spec/index.md # Model Context Protocol specification !!! info "Reference" **Citation:** Model Context Protocol project. "Model Context Protocol specification." **Type:** standard. **Link:** [modelcontextprotocol.io](https://modelcontextprotocol.io). ## What it is The specification for the Model Context Protocol. It defines MCP servers and tools, the interface substrate through which agents reach data and endpoints. ## Role in the record - Grounds [BP03](../best-practices/03-register-and-vet-interfaces.md): the interface substrate that registration and vetting practices concern. - Grounds [BP06](../best-practices/06-design-around-user-tasks.md): the interface substrate that the design practice concerns. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # Common Elements of Frontier AI Safety Policies (2025) Source: https://aiforscience.eu/library/ref-metr-common-elements-2025/index.md # Common Elements of Frontier AI Safety Policies (2025) !!! info "Reference" **Citation:** METR. "Common Elements of Frontier AI Safety Policies" (2025). **Type:** report. **Link:** [metr.org/common-elements](https://metr.org/common-elements). ## What it is An independent synthesis of frontier AI safety policies. It finds a shared capability-threshold structure across CBRN, cyber, and autonomy. ## Role in the record - Grounds [BP10](../best-practices/10-screen-dual-use-high-consequence.md): evidence that the high-consequence category is generic, with one capability-threshold structure recurring across domains. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # AI tools cite retracted papers (MIT Technology Review 2025) Source: https://aiforscience.eu/library/ref-mit-tech-review-retracted-2025/index.md # AI tools cite retracted papers (MIT Technology Review 2025) !!! info "Reference" **Citation:** MIT Technology Review. "AI models are using material from retracted scientific papers," 23 September 2025. **Type:** report. **Link:** [technologyreview.com](https://www.technologyreview.com/2025/09/23/1123897/ai-models-are-using-material-from-retracted-scientific-papers/). ## What it is A report finding that AI research assistants draw on and cite retracted papers. The tools present the retracted work without flagging its status. ## Role in the record - Grounds [BP07](../best-practices/07-provenance-and-citation.md): evidence that AI research tools cite retracted papers without flagging them. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # Model Cards for Model Reporting (2019) Source: https://aiforscience.eu/library/ref-model-cards-2019/index.md # Model Cards for Model Reporting (2019) !!! info "Reference" **Citation:** Mitchell, M. et al. "Model Cards for Model Reporting." *Proceedings of FAccT '19* (2019). **Type:** paper. **Link:** [doi:10.1145/3287560.3287596](https://doi.org/10.1145/3287560.3287596). ## What it is A short structured document that reports a trained model's intended use, performance across conditions, and known limitations. It standardises how models are described to users and reviewers. ## Role in the record - Grounds [BP05](../best-practices/05-documentation-and-data-for-agents.md): structured model documentation. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # Web-scraping AI bots disrupt scientific databases (Nature news, 2025) Source: https://aiforscience.eu/library/ref-nature-scraping-bots-2025/index.md # Web-scraping AI bots disrupt scientific databases (Nature news, 2025) !!! info "Reference" **Citation:** "Web-scraping AI bots cause disruption for scientific databases and journals." Nature (news), 2 June 2025. **Type:** news report. **Link:** [nature.com](https://www.nature.com/articles/d41586-025-01661-4). ## What it is A news report on automated bots harvesting open scientific resources for AI training data at volumes that degrade or break access for legitimate users. The image repository DiscoverLife (about 3 million species photographs) began taking millions of daily hits in early 2025 and slowed to the point that it no longer loaded. It gives named, dated instances of the load problem that the COAR survey ([coar-ai-bots-2025](ref-coar-ai-bots-2025.md)) reports in aggregate. ## Role in the record - Grounds [BP02](../best-practices/02-default-to-agent-accessibility.md): a concrete case that open resources face heavy automated load, and that scraping a resource with no clean interface degrades service for everyone. - Corroborates the [Failures log](../best-practices/failures.md) entry on agents falling back to scraping or legacy endpoints when no task-shaped interface exists. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # NeurIPS Paper Checklist Source: https://aiforscience.eu/library/ref-neurips-checklist/index.md # NeurIPS Paper Checklist !!! info "Reference" **Citation:** NeurIPS. "NeurIPS Paper Checklist." **Type:** guidance. **Link:** [neurips.cc/public/guides/PaperChecklist](https://neurips.cc/public/guides/PaperChecklist). ## What it is A checklist authors complete for NeurIPS submissions. It covers reproducibility and evaluation reporting for machine-learning research. ## Role in the record - Grounds [BP08](../best-practices/08-evaluate-tools-before-trust.md): reproducibility and evaluation reporting practice. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # NISO CREC (RP-45-2024) Source: https://aiforscience.eu/library/ref-niso-crec-2024/index.md # NISO CREC (RP-45-2024) !!! info "Reference" **Citation:** NISO. "Communication of Retractions, Removals, and Expressions of Concern (CREC)." NISO Recommended Practice RP-45-2024 (2024). **Type:** standard. **Link:** [www.niso.org/publications/rp-45-2024-crec](https://www.niso.org/publications/rp-45-2024-crec). ## What it is A recommended practice for how retractions, removals, and expressions of concern are communicated across the scholarly record. It defines consistent signals that both systems and people can act on. ## Role in the record - Grounds [BP07](../best-practices/07-provenance-and-citation.md): transmitting retraction status to machine and human readers. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # NIST AI Risk Management Framework (2023, 2024) Source: https://aiforscience.eu/library/ref-nist-ai-rmf/index.md # NIST AI Risk Management Framework (2023, 2024) !!! info "Reference" **Citation:** NIST. "Artificial Intelligence Risk Management Framework (AI 100-1)" (2023) and "Generative AI Profile (NIST AI 600-1)" (2024). **Type:** guidance. **Link:** [nist.gov/itl/ai-risk-management-framework](https://www.nist.gov/itl/ai-risk-management-framework). ## What it is A voluntary framework for managing AI risk across a GOVERN, MAP, MEASURE, MANAGE cycle. The Generative AI Profile adds guidance specific to generative systems, including a system inventory and stop-build authority. ## Role in the record - Grounds [BP04](../best-practices/04-govern-autonomy-and-accountability.md): defined roles and accountability, an agent inventory, and go/no-go authority. - Grounds [BP09](../best-practices/09-human-in-the-loop.md): oversight calibrated to the risk level. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # OECD AI Principles (2019, updated 2024) Source: https://aiforscience.eu/library/ref-oecd-ai-principles-2024/index.md # OECD AI Principles (2019, updated 2024) !!! info "Reference" **Citation:** OECD. "OECD AI Principles" (2019, updated 2024). **Type:** policy. **Link:** [oecd.org/en/topics/ai-principles.html](https://www.oecd.org/en/topics/ai-principles.html). ## What it is Intergovernmental principles for trustworthy AI. They cover human agency, transparency, accountability, and traceability. ## Role in the record - Grounds [BP04](../best-practices/04-govern-autonomy-and-accountability.md): traceability placed under the Accountability principle; human agency and oversight. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # Practices for Governing Agentic AI Systems (2023) Source: https://aiforscience.eu/library/ref-openai-governing-agentic-ai-2023/index.md # Practices for Governing Agentic AI Systems (2023) !!! info "Reference" **Citation:** OpenAI. "Practices for Governing Agentic AI Systems" (2023). **Type:** report. **Link:** [cdn.openai.com/papers/practices-for-governing-agentic-ai-systems.pdf](https://cdn.openai.com/papers/practices-for-governing-agentic-ai-systems.pdf). ## What it is A report on governance practices for agentic AI systems. It proposes measures to keep operation safe as agents take actions on behalf of users. ## Role in the record - Grounds [BP04](../best-practices/04-govern-autonomy-and-accountability.md): constraining the action space, human accountability, and an action ledger. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # Open and Sustainable AI in the life sciences (OSAI, 2025) Source: https://aiforscience.eu/library/ref-osai-2025/index.md # Open and Sustainable AI in the life sciences (OSAI, 2025) !!! info "Reference" **Citation:** Farrell, G. et al. "Open and Sustainable AI: challenges, opportunities and the road ahead in the life sciences." *arXiv:2505.16619* (2025). **Type:** guidance. **Link:** [arXiv:2505.16619](https://arxiv.org/abs/2505.16619). ## What it is A community framework, the Open and Sustainable AI (OSAI) recommendations, addressing reproducibility and reusability of AI outputs in the life sciences. It maps its recommendations across the components of the AI ecosystem so that data, software, and models can be shared, reproduced, and reused transparently. ## Role in the record - Grounds [BP05](../best-practices/05-documentation-and-data-for-agents.md): openness and documentation that make data, software, and models reusable in line with FAIR. - Grounds [BP07](../best-practices/07-provenance-and-citation.md): reproducibility and traceability of AI-related work. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # OWASP Top 10 for LLM Applications 2025 Source: https://aiforscience.eu/library/ref-owasp-llm-top10-2025/index.md # OWASP Top 10 for LLM Applications 2025 !!! info "Reference" **Citation:** OWASP. "OWASP Top 10 for LLM Applications 2025." **Type:** guidance. **Link:** [owasp.org/www-project-top-10-for-large-language-model-applications](https://owasp.org/www-project-top-10-for-large-language-model-applications/). ## What it is A ranked list of the top security risks for applications built on large language models. It is maintained by the OWASP community. ## Role in the record - Grounds [BP03](../best-practices/03-register-and-vet-interfaces.md): prompt injection (LLM01) is the top-ranked risk; the documented risk that vetting guards against. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # OWASP MCP Top 10 Source: https://aiforscience.eu/library/ref-owasp-mcp-top10/index.md # OWASP MCP Top 10 !!! info "Reference" **Citation:** OWASP. "OWASP MCP Top 10." **Type:** guidance. **Link:** [owasp.org/www-project-mcp-top-10](https://owasp.org/www-project-mcp-top-10/). ## What it is A ranked list of security risks specific to the Model Context Protocol. It is maintained by the OWASP community. ## Role in the record - Grounds [BP03](../best-practices/03-register-and-vet-interfaces.md): MCP03 Tool Poisoning as a schema/supply-chain compromise of agent interfaces. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # W3C PROV-O (2013) Source: https://aiforscience.eu/library/ref-prov-o-2013/index.md # W3C PROV-O (2013) !!! info "Reference" **Citation:** W3C. "PROV-O: The PROV Ontology." W3C Recommendation, 30 April 2013. **Type:** standard. **Link:** [www.w3.org/TR/prov-o](https://www.w3.org/TR/prov-o/). ## What it is An ontology for expressing provenance: which entities, activities, and agents produced a result and how. It renders provenance as machine-readable, interoperable statements. ## Role in the record - Grounds [BP07](../best-practices/07-provenance-and-citation.md): machine-readable provenance. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # REFORMS reporting standards (2024) Source: https://aiforscience.eu/library/ref-reforms-2024/index.md # REFORMS reporting standards (2024) !!! info "Reference" **Citation:** "REFORMS: Consensus-based Recommendations for Machine-learning-based Science." *Science Advances* (2024). **Type:** standard. **Link:** [doi:10.1126/sciadv.adk3452](https://doi.org/10.1126/sciadv.adk3452). ## What it is A consensus set of reporting standards for machine-learning-based science. It defines what to report so results can be evaluated and reproduced. ## Role in the record - Grounds [BP08](../best-practices/08-evaluate-tools-before-trust.md): consensus reporting standards for machine-learning-based science. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # Dual use of AI-powered drug discovery (2022) Source: https://aiforscience.eu/library/ref-urbina-dual-use-2022/index.md # Dual use of AI-powered drug discovery (2022) !!! info "Reference" **Citation:** Urbina, F., Lentzos, F., Invernizzi, C. & Ekins, S. "Dual use of artificial-intelligence-powered drug discovery." *Nature Machine Intelligence* 4, 189-191 (2022). **Type:** paper. **Link:** [doi:10.1038/s42256-022-00465-9](https://doi.org/10.1038/s42256-022-00465-9). ## What it is A toxicity-prediction model was inverted to design toxic molecules. It generated 40,000 candidate toxic molecules, including VX and other known chemical-warfare agents, in under 6 hours. ## Role in the record - Grounds [BP10](../best-practices/10-screen-dual-use-high-consequence.md): the sharpest non-life-science instance that dual-use misuse capability is real, supporting screening before an agent is given reach. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # US policy for oversight of Dual Use Research of Concern (2024) Source: https://aiforscience.eu/library/ref-usg-durc-2024/index.md # US policy for oversight of Dual Use Research of Concern (2024) !!! info "Reference" **Citation:** US OSTP. "United States Government Policy for Oversight of Dual Use Research of Concern and Pathogens with Enhanced Pandemic Potential: Implementation Guidance" (2024). **Type:** policy. **Link:** [bidenwhitehouse.archives.gov](https://bidenwhitehouse.archives.gov/wp-content/uploads/2024/05/USG-DURC-PEPP-Implementation-Guidance.pdf). ## What it is A codified US dual-use oversight instrument. It is scoped to the life sciences and is under 2025 revision. ## Role in the record - Grounds [BP10](../best-practices/10-screen-dual-use-high-consequence.md): a mature worked example of dual-use oversight. Because it is scoped to the life sciences and under revision, the practice is framed on the general concept, not this instrument. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # Fabricated citations from LLMs (Walters & Wilder 2023) Source: https://aiforscience.eu/library/ref-walters-wilder-2023/index.md # Fabricated citations from LLMs (Walters & Wilder 2023) !!! info "Reference" **Citation:** Walters, W. H. and Wilder, E. I. "Fabrication and errors in the bibliographic citations generated by ChatGPT" (2023). **Type:** paper. **Link:** [PMC11031695](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC11031695/). ## What it is A study measuring the accuracy of citations produced by a large language model. It finds that a large share of the generated references are fabricated or contain substantive errors. ## Role in the record - Grounds [BP01](../best-practices/01-match-method-to-task.md): fabricated citations are a failure mode of using a frontier LLM where a specialized retrieval method fits. - Grounds [BP07](../best-practices/07-provenance-and-citation.md): evidence that a large fraction of LLM-generated citations are fabricated or erroneous (support for requiring a source trail). Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # Nucleic-acid biosecurity screening vs generative protein design (2025) Source: https://aiforscience.eu/library/ref-wittmann-biosecurity-2025/index.md # Nucleic-acid biosecurity screening vs generative protein design (2025) !!! info "Reference" **Citation:** Wittmann, B. J. et al. "Nucleic-acid biosecurity screening versus generative protein design." *Science* (2025). **Type:** paper. **Link:** [doi:10.1126/science.adu8578](https://doi.org/10.1126/science.adu8578). ## What it is A test of biosecurity screening against AI-designed sequences. The designed sequences evaded synthesis screening; patches restored detection. ## Role in the record - Grounds [BP10](../best-practices/10-screen-dual-use-high-consequence.md): the life-science instance that dual-use misuse capability is real and that screening must be maintained. Atom-level for/against detail and quotes are in the provenance data (`assets/provenance.yml`), keyed by practice atom. --- # Contribute Source: https://aiforscience.eu/about/contribute/index.md # Contribute Everything on this site is maintained in a public GitHub repository: [slolab/aiforscience.eu](https://github.com/slolab/aiforscience.eu). All routes into the record run through it. ## Ways to contribute **Propose a practice.** You have observed something that works and holds up. Use the [Propose a practice](https://github.com/slolab/aiforscience.eu/issues/new/choose) issue template. State the practice as an imperative, the context in which it was learned, and the evidence. **Challenge a practice.** You disagree with a practice, or your experience contradicts it. Use the "Challenge a practice" template. Challenges with concrete cases are the most useful input the record gets. **Submit a document.** Your organisation has a strategy paper, report, or guideline the record should digest. Use the "Submit a document" template with a link or DOI. An editor distills it into a [Library](../library/index.md) entry, with an AI-assisted draft reviewed by humans before anything is published. **Discuss.** For open-ended topics, use [GitHub Discussions](https://github.com/slolab/aiforscience.eu/discussions). Each practice page also has a discussion thread at the bottom. **No GitHub account?** Use the [AI for Science Google Group](https://groups.google.com/g/aiforscience), or write to [aiforscience@googlegroups.com](mailto:aiforscience@googlegroups.com). Proposals, challenges, and comments sent there are carried into the record by the editors, with attribution unless you ask otherwise. **Edit directly.** Every page has an edit button that opens a pull request. Follow the conventions in the repository's CLAUDE.md (page structure, metadata schema, writing style). ## Editorial standards - Short declarative sentences. Every word carries information. - Claims cite sources; distillations cite section and page. - Neutral coalition voice: the record speaks for its contributors collectively, never for a single institution. ## What happens to your contribution Editors review all input in the open. Accepted practices start as **draft**, move to **reviewed** when the editor group accepts them, and to **endorsed** when a named organisation formally backs them. See [Governance](governance.md) for details. --- # Events Source: https://aiforscience.eu/about/events/index.md # Events The record is maintained in the open, and part of that happens live. ## Monthly meeting An open call, once a month. The editor group walks through what moved: practices under discussion, new challenges, documents entering the library. Anyone may join, listen, or bring a case. Date, time, and joining link are announced in [GitHub Discussions](https://github.com/slolab/aiforscience.eu/discussions). ## Other events Workshops, task-force sessions, and talks are listed here as they are scheduled. Announcements also appear in [GitHub Discussions](https://github.com/slolab/aiforscience.eu/discussions). --- # Governance Source: https://aiforscience.eu/about/governance/index.md # Governance The record is open for input and curated for output. Anyone can propose, challenge, or discuss. A small editor group decides what is merged. ## Roles - **Contributors**: anyone. Contributions come in through issues, discussions, and pull requests. No affiliation is required. - **Editors**: a small group drawn from the contributing task forces. Editors review contributions, maintain editorial standards, and merge changes. The current editors are listed in the repository's [README](https://github.com/slolab/aiforscience.eu#readme). - **Endorsing organisations**: organisations that formally back specific practices after their own review. Endorsements are recorded in the practice's metadata. ## How changes happen 1. A change is proposed: through an [issue template](https://github.com/slolab/aiforscience.eu/issues/new/choose), a [discussion](https://github.com/slolab/aiforscience.eu/discussions), or directly as a pull request. 2. Editors review. Discussion happens in the open, on the issue or pull request. 3. Any change that alters a practice's status or adds an endorsement requires review by a second editor before merge. 4. Merged changes appear on the live site immediately and are summarised in the next monthly [release](../releases/index.md). ## Practice lifecycle Practices move through three statuses: **draft** (proposed, under discussion), **reviewed** (accepted by the editor group), **endorsed** (formally backed by at least one named organisation). A practice can also be retired; retired practices remain in the git history and in dated releases. ## Disagreement Disagreement is valuable content. If organisations or contributors hold different positions on a practice, the practice page records the positions and who holds them, rather than forcing a false consensus. The "Challenge a practice" issue template exists for exactly this. --- # How the record works Source: https://aiforscience.eu/about/how-the-record-works/index.md # How the record works This is a running document. It is revised as the field develops, discussed in regular task force meetings, and versioned for citation. The live site always shows the current state; dated snapshots are available under [Releases](../releases/index.md). The practices run from the most general (decisions that hold across resources and institutions) to the most specific (per-use-case mechanics). ## How practices are recorded Each practice has a page with the same structure: the statement, why it matters, what it looks like in practice, what it means for each audience, and its sources. Metadata at the top records the review status and which organisations endorse it. Practices link back to [library](../library/index.md) entries, which quote the source passages with locators. ## How practices are gated The record keeps a small number of high-impact practices. A new one gets its own page only if it passes all of these: 1. **Scope.** It changes how science is planned, performed, evaluated, communicated, or governed (the [mission](mission.md) test). 2. **Generality.** It applies across audiences or many resources, not to a single service. 3. **Not a sub-case.** If it is a narrower version of an existing practice, it becomes a "what it looks like in practice" bullet on that page, not a new page. This is the main way we avoid bloat. 4. **Backed.** It is supported by an identified library entry or task-force observation. 5. **Distinct action.** A reader could do something differently because of it. We merge rather than add. A source that agrees with an existing practice grounds it (a note and a citation) instead of creating a new one. A source with no bearing on practice is recorded as such, so the question is not reopened. ## Status legend | Status | Meaning | |---|---| | draft | Proposed, under discussion. | | reviewed | Accepted by the editor group. | | endorsed | Formally backed by at least one named organisation or task force. | --- # Mission Source: https://aiforscience.eu/about/mission/index.md # Mission ## Vision Science that uses agentic AI well: agents do the connecting, scientists keep the thinking. Agentic AI is most valuable in science when it links data, tools, and models across groups and institutions, while the epistemic core of research (judgement, provenance, accountability) stays with humans. ## Mission Maintain the shared, citable, current record of best practices for applying agentic AI to science. Guidance written as static reports is outdated before it is published; this record is revised at the pace of the field, versioned for citation, and open to challenge. It aggregates what task forces and institutions learn, so organisations build on each other's experience instead of writing siloed reports. ## Scope Current developments around generative AI, particularly large language models, impact fundamentally how science is done. This living document aims to capture anything that matters in this frame. The test for any practice, document hook, or discussion: > Would adopting this change how science is planned, performed, evaluated, > communicated, or governed? **In scope**: research workflows and methods; scientific services, data resources, and infrastructure; provenance, citation, and evaluation of agentic systems; research skills and training; governance of AI within scientific institutions. **Out of scope**: national economic and industrial policy, energy and compute geopolitics, security and defence, international treaties. When such material directly constrains scientific practice, the record cites it as context; it does not distill or debate it. The record also draws a method boundary. It covers the practice of applying agents to scientific work. The design and validation of AI methods as scientific instruments (predictors, generative models, classifiers) have their own established community norms (FAIR, DOME, model cards, datasheets, REFORMS). The record cites these rather than restating them, and treats an agent or model as a method chosen for a task, not a default (see [Match the method to the task](../best-practices/01-match-method-to-task.md)). The same test governs the [library](../library/index.md): a distillation of a broad policy report keeps the passages that fit into this scope. ## Audiences The record is written for three roles. There are overlaps, and most practices speak to more than one; practice pages carry audience-specific section for each. - **Practitioners**: scientists and research groups using agentic AI in their daily work. - **Providers**: the people who build and operate scientific services, data resources, and tools that agents use (for example the teams behind research-infrastructure services). - **Governance**: scientific management, from institute leadership to head offices and funders, deciding what to enable, require, and resource. ## How the record is made Two groups shape adoption. **Pioneers** adopt early and learn by doing; they exist in every audience but concentrate among practitioners. The best support for them is to remove obstacles and observe. Pioneers write these practices or ignore them; either is fine. **Settlers** are far more numerous. They come after the pioneers and build things meant to last, so they need reliable, current guidance. The practices are learned from the first group and written for the second, across all three audiences. ## How it stays current The record is maintained on [GitHub](https://github.com/slolab/aiforscience.eu). Changes go through public review. A dated release is cut monthly and receives a DOI, so the record can be cited by scientists and by institutional strategy documents alike. Every practice records which organisations endorse it, and any organisation can propose, challenge, or endorse practices; the value of the shared record grows with every organisation that joins. See [Partners](partners.md), [Governance](governance.md), and [Releases](../releases/index.md). --- # Partners Source: https://aiforscience.eu/about/partners/index.md # Partners The record is shaped by the organisations that contribute to it and endorse its practices. Endorsement is recorded per practice, not wholesale: an organisation backs the specific statements it has reviewed. ## Contributing organisations - **Helmholtz AI**: task force on AI for science; origin of the running best practice model used here. ## Joining The record is designed to aggregate effort, not to compete with local and national initiatives. If your organisation maintains its own guidance on agentic AI in science, there are three ways to connect it: 1. **Submit documents.** Strategy papers and reports are distilled into [Library](../library/index.md) entries that cite the original and map it to the practices. 2. **Propose and challenge practices.** Task forces and working groups can feed their findings in through the [issue templates](https://github.com/slolab/aiforscience.eu/issues/new/choose). 3. **Endorse practices.** After review, an organisation can be listed as endorsing specific practices, which raises the practice's status and the record's weight. To start a conversation, open a [discussion](https://github.com/slolab/aiforscience.eu/discussions), write to the [AI for Science Google Group](https://groups.google.com/g/aiforscience), or contact the editors (see [Governance](governance.md)). --- # Releases Source: https://aiforscience.eu/releases/index.md # Releases The live site always shows the current state of the record. For citation, dated snapshots are cut monthly as git tags and [GitHub releases](https://github.com/slolab/aiforscience.eu/releases). Each release receives a DOI via Zenodo. !!! note "No releases yet" The first dated release will be cut when the first practices land. ## How to cite Once releases exist, cite the record by release, not by URL alone: > AI for Science contributors. *Best Practices for Agentic AI in Science*, > release YYYY.MM. https://aiforscience.eu, DOI: (assigned per release via > Zenodo). --- # Glossary Source: https://aiforscience.eu/glossary/index.md # Glossary The basic terms, as this site uses them. The list grows with the record. If a term is missing or unclear, [open an issue](https://github.com/slolab/aiforscience.eu/issues/new/choose).
Agent { #agent } : A system built around a language model that carries out multi-step work: it plans, calls tools, reads the results, and decides what to do next. The model supplies the reasoning; the surrounding [harness](#harness) does the acting. Distinct from a chat model that answers one prompt at a time. Agentic AI { #agentic-ai } : The use of agents for real work. In science: literature triage, data analysis, coding, drafting. The subject of this record. Distinct from AI used as a scientific instrument (a predictor, a generative model, a classifier), which has its own established norms. The record treats an agent or model as a method chosen for a task rather than a default, and cites those norms rather than restating them (see [Match the method to the task](best-practices/01-match-method-to-task.md)). Best practice { #best-practice } : A numbered, versioned statement of what works, written as an imperative. Each practice carries a status, its sources, and the organisations that endorse it. Challenge { #challenge } : A documented disagreement with a practice, ideally with a concrete case where the practice fails. Challenges are the main input that drives revision. Confabulation { #confabulation } : A confident, fluent output from a language model that is not grounded in fact, also called hallucination. Because it reads like a correct answer, it is caught by checking against sources, not by judging how plausible it looks. Distillation { #distillation } : The process behind the [Library](library/index.md). A strategy paper or report is condensed into a cited entry and mapped to the practices it supports or contradicts. Dual use { #dual-use } : Knowledge, tools, or capabilities that serve legitimate research and can also be turned to serious harm, for example designing a toxin, uplifting a cyberattack, or enhancing a pathogen. A dual-use request to an agent is one whose output could enable such harm, which is why high-consequence capabilities are screened (see [Screen agents for dual-use and high-consequence risk](best-practices/10-screen-dual-use-high-consequence.md)). Endorsement { #endorsement } : A named organisation's formal backing of a practice. Recorded in the practice's metadata, never implied. Guardrails { #guardrails } : Limits on what an agent can do, enforced by the system that runs it rather than stated only in policy. They take the form of permission scopes, autonomy limits, stop and escalation conditions, and shutdown paths. An agent cannot be talked out of a guardrail; it can only be stopped from taking the action (see [Govern agent autonomy and accountability](best-practices/04-govern-autonomy-and-accountability.md)). Harness { #harness } : Everything in an agent except the language model itself: the loop that runs it, the tools and [interfaces](#interface) it can call, and the connections to outside systems. The model decides what to do; the harness carries it out. Human in the loop (HITL) { #hitl } : A human checkpoint in an agentic workflow. Each practice states what oversight it requires: mandatory, optional, during the process, or as a final check. Interface { #interface } : A component added to an agent's [harness](#harness) so it can reach a tool, data source, or action outside the model, for example an [MCP](#mcp) server, a skill, or a plugin. An interface runs code and acts for the user, so it is where much of the risk enters, which is why interfaces are registered and vetted (see [Register, vet, and manage agent interfaces](best-practices/03-register-and-vet-interfaces.md)). Living record { #living-record } : This site. The live version is always current. Monthly dated releases, each with a DOI, exist for citation. See [Releases](releases/index.md). Machine-actionable { #machine-actionable } : Data, metadata, and documentation structured so software can find, read, and act on it without a human interpreting it first. It is the founding goal of the FAIR principles, which agents now make concrete. Machine-readable is the weaker form: a program can parse the content but still needs a human to know what it means. MCP (Model Context Protocol) { #mcp } : An open standard for connecting an agent to external tools, data, and actions. An MCP server is a common kind of [interface](#interface): it exposes a set of tools an agent can call. Used throughout this record as the running example of an agent interface, alongside skills and plugins. Pioneer { #pioneer } : An early adopter who learns by doing. What pioneers learn is where the practices come from. Prompt injection { #prompt-injection } : An attack that hides instructions inside content an agent reads (a web page, a document, a tool description), so the model follows them as if they came from the user. The user never sees the injected text, which is what makes it dangerous. Tool poisoning is one form, where the hidden instructions sit in an [interface's](#interface) tool description. Settler { #settler } : The larger group that follows the pioneers and builds things meant to last. The practices are written for them. Status { #status } : Where a practice stands. `draft`: proposed, under discussion. `reviewed`: accepted by the editor group. `endorsed`: formally backed by at least one named organisation or task force.
--- # AI for Science Source: https://aiforscience.eu/index.md

One shared record

Everything cited, versioned, and open to challenge.

Practices →

Numbered, versioned practices, each with reasons, examples, and sources.

Library →

The evidence base behind every citation, annotated and kept current.

Challenge →

Disagree with a practice? Challenges are formal, public, and logged.

Get involved

Discussion →

Questions, debate, and proposals, in the open. Start a thread or challenge a practice at any time.

Also: propose or challenge a practice · submit a document.

--- # Tags Source: https://aiforscience.eu/tags/index.md # Tags Browse the record by audience (practitioner, provider, governance) and status.