Skip to content

5. Blueprint Considerations

This Blueprint sets out an ambitious range of capabilities, and implementers will encounter tensions and contradictions between principles and features that must be navigated according to context. This section sets out the conditions that any implementation must satisfy before the architecture principles in Section 6 can be meaningfully put into practice. It addresses six areas: governance of the Data Director as an agentic AI system, covering agent behaviour, automation boundaries and human oversight; governance of the data on which it operates, covering legal, ethical and sovereignty requirements; how to resolve conflicts between requirements; operational readiness for deployment; and costs, sustainability and evaluation. Together these provide the foundation from which all other implementation decisions follow.

Both agentic AI governance and research data governance are large, complex, and rapidly evolving fields that extend well beyond the scope of this Blueprint. The considerations set out here are not intended to be exhaustive but to provide implementers with a principled starting point for trustworthy and sustainable deployment. Automation should proceed where governance conditions have been defined and met, not simply because a capability is technically available. Beyond these foundational constraints, implementers have the freedom to configure, prioritise, and extend the Data Director's capabilities in ways appropriate to their institutional, disciplinary, and jurisdictional context, and are encouraged to engage with relevant national frameworks, institutional policies, and emerging community standards as these fields develop.

5.1 Governance and Roles

  • Define accountable human roles and responsibility assignments before configuring the tool. Who approves consequential decisions, who resolves policy exceptions, and who maintains configuration must be documented in governance agreements. Where multiple institutions collaborate, a dedicated inter-institutional framework agreement should be in place before deployment.

  • Establish a policy priority hierarchy before implementation. Where institutional, funder, journal, and disciplinary requirements conflict, a documented resolution order must exist. The tool can surface conflicts but cannot resolve them without human-defined precedence rules.

  • Determine the level of human oversight required for each workflow before configuring automation. Distinguish between actions requiring explicit human approval and those requiring ongoing monitoring. Where a DMP exists, discrepancies with actual data publication should trigger human review rather than automatic blocking, since a DMP is a plan and not a binding contract.

  • Treat legal, ethical, and human rights compliance as prerequisites for any sharing action. Legal and ethical permissibility must be confirmed before workflows are enabled. Relevant ethics approval body status, such as an Institutional Review Board (IRB), Research Ethics Committee (REC), or equivalent national body, must be verified before data publication proceeds, and embargo status must be confirmed by the responsible human before any sharing workflow is triggered.

  • Protect sensitive data from unauthorised access or ingestion at all stages of the workflow. Sensitive, personal, or legally restricted data must not be ingested by the large language model component of the tool without explicit institutional authorisation and appropriate legal safeguards. Technical controls must be in place to enforce this.

  • Resolve data residency and cross-border transfer requirements at the architecture stage. Implementers must document how AI processing, logs, temporary files, and backups will be managed within jurisdictional boundaries. Practical approaches to achieving this depend on institutional infrastructure.

  • Ensure data sovereignty and community authority inform openness decisions from the outset, not retrospectively. Indigenous data rights and national sovereignty obligations are conditions that shape what can be shared, not constraints to be accommodated afterwards. CARE principles must be applied as design inputs and must not be treated as a uniform standard, given significant variation across domains and communities.

5.3 Resolving Conflicting Requirements

Implementations will encounter genuine conflicts between requirements that cannot be resolved by the tool alone. Several architectural principles set out in Section 6 (Table 2) pull in opposing directions, and implementers must be prepared to make deliberate, documented decisions about how to resolve them. The following requirements apply to all implementations:

  • Document how conflicts between principles have been resolved and make that reasoning visible to users and auditors. Resolution decisions must be recorded and communicated rather than left implicit in configuration choices.

  • Open data must remain openly accessible regardless of the security or encryption measures applied to the underlying infrastructure. Encryption at rest and in transit protects infrastructure and must not be used to restrict access to datasets that are designated as open.

5.4 AI Behaviour and Automation

  • Ensure that agents do not operate anonymously. All agent actions must be executed on behalf of a named, identified human user, and both the agent identity and the human it acts for must form part of the provenance record. Where an agent acts on behalf of an institution rather than an individual, a designated accountable human role must be defined and documented.

  • Require that all agent actions on data and metadata are recorded and traceable, consistent with functional requirement R10 in Section 7.1. A recognised provenance standard such as PROV-O1 should be adopted to ensure records are structured, interoperable, and auditable.

  • Where a dataset arrives with existing provenance information, the Data Director must preserve and carry forward that record rather than replacing or discarding it; new agent actions are appended to the existing provenance chain.

  • Enable automation only where governance conditions have been defined and met, not simply because a capability is technically available. Consequential decisions must remain with accountable humans. Override rights for AI outputs must be role-based and governed, not open to all users.

  • Where personal identifiers or sensitive information are flagged or detected, the tool must pause the sharing process rather than acting autonomously. The researcher must be directed to appropriate external anonymisation or deidentification workflows before the sharing process can proceed.

  • Define explicit agent behaviour for when no controlled vocabulary, ontology, or community standard exists. The tool must state the absence openly rather than falling back silently to general-purpose alternatives. In domains where no prior FAIR work has taken place, outputs may be entirely generic; implementations must detect and record this condition, communicate it clearly to the user, and include it in the provenance chain.

  • Prevent poor-quality AI-generated metadata from reaching repositories. Quality checks on AI outputs must be a core capability, not an optional enhancement. Generic, uncurated, or inaccurate outputs must be flagged for mandatory human review before submission. This is distinct from FAIR assessment, which evaluates metadata against recognised external standards.

5.5 Operational Readiness

  • Define rollback and recovery mechanisms that do not compromise traceability or auditability. Recovery to a known good state must be designed alongside provenance tracking so that interpretability and auditability are maintained through failure and recovery events.

  • Assess whether sufficient technical, policy, and data management capacity exists to configure and maintain the tool before proceeding with deployment. This includes the availability of staff who can manage technical configuration, maintain policy mappings as requirements change, and provide human oversight of AI-generated outputs.

  • Guard against over-reliance on the tool, which can erode in-house research data management expertise over time. Deployment should be accompanied by investment in researcher and data professional skills, as noted in Section 3.1.3.

  • Calibrate reliability and uptime targets to the deployment context. Commitments appropriate for national infrastructure are not realistic for locally hosted or resource-constrained deployments.

5.6 Costs, Sustainability and Evaluation

  • Make all implementation costs explicit and plan for the ongoing sustainability of the deployment from the outset. Costs to document include deposit fees, PID registration costs, per-unit AI processing costs, staff time for configuration and ongoing maintenance, and the risk of scaling costs as usage grows. Institutions should model costs at projected scale before committing to deployment.

  • Ensure that implementation decisions do not introduce features, add-ons, or dependencies that make the tool inaccessible to lower-resource institutions. Cost barriers and irreversible technical dependencies must be actively avoided, consistent with the affordability requirement set out in Section 7.2 (C17).

  • Establish a FAIRness baseline before deployment and define what metrics will demonstrate value over time.

  • Ensure the tool meets recognised digital accessibility standards and is operable in resource-constrained environments. Recommendations produced by the tool must be evaluated for implicit bias to ensure underrepresented communities and non-dominant metadata standards are not systematically excluded.

  1. https://www.w3.org/TR/prov-o/ ↩