Overview

Lesson 3.3: Data Governance for AI Research

This lesson teaches you how to establish governance structures for research data when AI systems play a role. You'll learn to design access control policies that balance openness with protection, maintain audit trails documenting who accessed data when and why, establish retention and disposal policies, and navigate the complexities of sharing sensitive data across institutions when AI has processed or will process it.

Title

Lesson 3.3: Data Governance for AI Research

Purpose

This lesson teaches you how to establish governance structures for research data when AI systems play a role. You'll learn to design access control policies that balance openness with protection, maintain audit trails documenting who accessed data when and why, establish retention and disposal policies, and navigate the complexities of sharing sensitive data across institutions when AI has processed or will process it.

Why Data Governance Matters for AI Research

Data governance is the framework of policies, processes, roles, and responsibilities that determine how data is managed throughout its lifecycle. In traditional research contexts, governance often meant deciding who could access sensitive participant data or how long records should be retained. AI changes the stakes dramatically.

When AI systems enter the research workflow, they interact with your data in ways that traditional governance frameworks never anticipated. An AI tool might ingest thousands of records to generate a summary. A large language model might be fine-tuned on your proprietary corpus. An automated analysis pipeline might access your raw data at 3am without any human review. Each of these interactions raises questions that your governance framework must address: Is this access authorized? Is it logged? Does it comply with participant consent? Are the outputs being retained appropriately?

Consider a concrete scenario. A neuroscience lab is using an AI tool to analyze patient imaging data. The tool runs on cloud infrastructure managed by a commercial vendor. The researchers authorized the tool to access the imaging folder, but they did not specify whether the vendor could use those images to improve their model. They did not establish whether AI-generated annotations should be retained alongside the raw images. They did not determine who is responsible when the AI misclassifies a scan. When questions arise, from their IRB, from a participant, from a collaborator institution, the lab has no clear answers because governance was never established.

This gap is not unusual. Most research governance frameworks were designed before AI became a substantive tool in the workflow. The frameworks addressed human access and human decisions. They are silent on automated access and machine-generated outputs. Your task as an advanced researcher is to close that gap proactively: before your IRB, your funder, or your institution forces you to do so reactively.

Good governance serves three purposes. First, it protects your research participants and subjects by ensuring their data is handled in accordance with their consent and applicable regulations. Second, it protects your research integrity by creating an accountable record of how decisions were made and who made them. Third, it protects you and your institution by demonstrating due diligence when questions arise.

Designing Access Control for AI Systems

Access control in traditional research settings typically involves human actors: a postdoc has read access to the dataset, a PI has read-write access, and collaborators at partner institutions have view-only access under a data sharing agreement. When AI tools enter the picture, access control becomes more complex because AI systems are not individual humans. They are services, APIs, or automated pipelines that may run continuously, at scale, and without direct human oversight.

The first principle of AI access control is the principle of least privilege: AI systems should have access to the minimum data necessary to accomplish their task. If your AI tool is analyzing transcripts from participant interviews to identify themes, it does not need access to participant demographic records. If an AI pipeline is checking statistical outputs for anomalies, it does not need raw individual-level data, only aggregated results. Granting broader access than necessary creates unnecessary risk: if the AI service is compromised or if the vendor's privacy practices are inadequate, more data is exposed.

The second principle is scoping access temporally. Unlike human researchers who have ongoing project roles, AI tool access should be time-limited. Create access tokens or credentials that expire, and require active renewal. An AI tool that was authorized for a specific analysis phase should not retain permanent access to your data repository. Temporal scoping also forces regular review: when the renewal period comes, you must consciously evaluate whether continued access is justified.

The third principle is distinguishing between reading, writing, and training. Some AI tools only read your data to produce outputs. Others may write outputs back to your data environment. Still others may use your data for model training or fine-tuning, which creates a persistent artifact (the trained model) that encodes information about your data. These three types of access have very different implications and should require different levels of authorization. Training on sensitive data, in particular, requires explicit consent analysis: if your participants consented to use of their data for research, did they consent to use of their data to train a commercial AI model? Often the answer is no, and this means fine-tuning on participant data may require new consent or may not be permissible.

Practically, implement AI access control through documented service accounts (not personal credentials), environment variable management for API keys, and data access logs that capture AI service requests separately from human access logs. Review these logs regularly, not just when something goes wrong.

Maintaining Audit Trails for AI Interactions

An audit trail is a chronological record of who accessed what data, when, and for what purpose. In regulated research environments, audit trails are often legally required. Even in contexts where they are not required, audit trails are essential for research accountability: they allow you to reconstruct how your analysis proceeded, identify the root cause of discrepancies, and demonstrate methodological rigor to reviewers and regulators.

AI systems create a new audit challenge because they may make thousands of data accesses in the time a human researcher would make one. A large language model processing a corpus of 10,000 documents does not create 10,000 individually reviewable decisions. It creates a single output that encodes its exposure to all 10,000 documents in an opaque way. Traditional audit approaches that log individual access events are insufficient for AI workflows.

Effective audit trails for AI research must capture several categories of information. First, document which AI system accessed which data, including the model version, the API endpoint, and the date range of access. Version information is critical: the same nominal tool may behave differently across model versions, and without version documentation, your audit trail cannot support reproducibility. Second, log the inputs provided to the AI: the prompts, the data slices, the parameters. Third, retain the outputs generated. AI outputs are research artifacts that should be versioned and stored, not treated as ephemeral intermediate products. Fourth, document human review: who reviewed the AI outputs, when, and what validation or correction was applied.

For automated pipelines, implement logging at the pipeline level. Every pipeline run should generate a structured log entry that captures the data source, the AI component used, the parameters, the output location, and the timestamp. Store these logs in a location separate from your primary data to ensure they persist even if data is later modified or deleted.

One practical approach is to treat AI interaction logs the same way you treat lab notebooks: they are primary research records that should be retained for the same period as your data and that should be submitted along with your data when you archive or publish. Some journals and data repositories are beginning to require AI interaction logs as part of data sharing requirements. Getting ahead of this requirement by building logging into your workflow from the start is far easier than reconstructing it after the fact.

Retention and Disposal Policies in AI Contexts

Research data retention policies specify how long data must be kept and when and how it may be disposed of. These policies exist for good reasons: they ensure that data supporting published findings can be audited and reproduced for a reasonable period, they prevent indefinite accumulation of sensitive data beyond its useful life, and they protect participants by limiting how long sensitive information persists.

AI research introduces several complications for retention and disposal. The first is the question of what counts as "the data." In a traditional research context, the data is the dataset: the spreadsheet, the images, the survey responses. In AI research, the data includes the dataset plus the prompts you used, the AI outputs, the model versions, the fine-tuned model weights (if any), and the interaction logs. Your retention policy must define which of these artifacts are research data subject to retention requirements and which are process documentation.

For most purposes, all of these artifacts should be treated as research records. A published paper that relied on AI-generated analyses should retain the AI outputs and the prompts used to generate them for at least as long as the paper's results need to be auditable, typically five to ten years under most institutional and funder policies.

Disposal of AI-processed data creates a unique problem: sanitization. When you dispose of traditional research data by deleting a file or wiping a drive, you can be reasonably confident the data is gone. When an AI model has been trained or fine-tuned on sensitive data, the model itself may encode information about that data. Deleting the training dataset does not delete the model's memory of it. This has led to legal and regulatory discussions about the "right to be forgotten" in AI contexts: if a participant withdraws consent, you can delete their individual records, but can you retrain or modify the model to remove their influence? Often you cannot, practically speaking. This means research using AI fine-tuning on sensitive participant data should include prospective analysis of withdrawal rights, and may require restricting fine-tuning to non-sensitive data or data from participants who have provided broad consent.

For disposal of AI outputs and logs that contain no sensitive information, standard secure deletion procedures apply. For disposal of AI systems or API connections, document the termination of access and confirm with vendors that your data has been removed from their systems, to the extent possible under your service agreement.

Cross-Institutional Data Sharing with AI Involvement

Research increasingly happens across institutional boundaries. Multi-site clinical trials, collaborative genomics consortia, and multi-institution social science studies all involve sharing data between organizations with different governance frameworks, different IRB requirements, and different compliance environments. AI adds substantial complexity to this already complex landscape.

The first complication is that when data crosses institutional boundaries to be processed by AI, questions of data residency and jurisdiction arise. A research dataset housed at a US university that is sent to a cloud AI service for processing may pass through servers in multiple countries, each with different data protection laws. If your dataset contains health information, financial information, or personal data from EU residents, these cross-border transfers may trigger HIPAA, GDPR, or other regulatory requirements. Your governance framework must address where data is processed, not just where it is stored.

The second complication involves data sharing agreements (DSAs) and whether they contemplate AI use. Traditional DSAs define what the receiving institution may do with the shared data: analyze it, publish aggregate results, retain it for a specified period. They typically do not address whether the receiving institution may process the data through AI tools, whether AI-generated outputs constitute new data products subject to the agreement, or whether the receiving institution may share the data with a third-party AI vendor. If you are entering into or updating a data sharing agreement for a project that will involve AI, add explicit provisions covering these questions. If you are operating under an existing DSA that predates your AI use, consult your institution's research compliance office before using AI tools with shared data.

A practical governance approach for cross-institutional AI research is the federated analysis model: rather than sharing raw data between institutions, keep data at each site and run AI analyses locally, sharing only aggregated results or model outputs. Federated learning, a machine learning paradigm in which models are trained locally and only model updates (not raw data) are shared, is a powerful tool for this purpose. It allows collaborative AI development without centralizing sensitive data, reducing both governance complexity and privacy risk.

Whenever you receive data from partner institutions, maintain records of the governance conditions under which it was shared, including any restrictions on AI processing. When you share your data with partners, specify your governance expectations for their AI use. These conversations are increasingly expected as standard practice in cross-institutional research, and initiating them proactively marks you as a mature, trustworthy collaborator.

Building Your Governance Framework: A Practical Approach

Governance frameworks can feel abstract: policies, roles, responsibilities, documentation requirements. The practical question is how to build one that actually works for your research context without becoming a bureaucratic burden that slows your work.

Start with a data inventory. Before you can govern your data, you need to know what you have. List every dataset your project uses, noting: its sensitivity level (public, internal, restricted, sensitive), its source (collected by your team, shared by partners, purchased, or scraped), the consent or use conditions under which it was obtained, and where it is stored. This inventory is not just a governance exercise. It is genuinely useful research infrastructure that will help you when collaborators ask about data, when reviewers ask about data sharing, and when you archive your project.

Then identify which datasets will interact with AI systems and classify those interactions by type: read-only analysis, output generation, or training. Apply the access control principles discussed earlier and document your decisions. A simple table recording the dataset name, the AI tool, the access type, the access conditions, and the responsible person is sufficient for most projects.

Next, define your logging requirements. Decide what information you will capture for AI interactions, where you will store it, and how long you will retain it. Make this concrete: identify the specific log files or database tables, assign someone responsible for maintaining them, and set a calendar reminder to review them periodically.

Finally, establish a governance review process. Governance is not a one-time exercise. It must adapt as your project evolves, as you add new AI tools, and as regulations change. Schedule a quarterly or semi-annual governance review where you revisit your data inventory, check access controls, review audit logs, and assess whether any new AI interactions have been added without governance documentation.

The goal is not perfect governance. It is good enough governance that is actually practiced. A simple framework that your team uses consistently is far more valuable than an elaborate framework that sits in a document nobody reads. Start simple, be consistent, and iterate as your needs grow.