Paper deep dive
AI Sandbox: Technical Report
Muhammad Waseem, Md Aidul Islam, Md Nasir Uddin Shuvo, Md Mahade Hasan, Kai-Kristian Kemell, Jussi Rasku, Mika Saari, Vilma Saari, Roope Pajasmaa, Markku Oivo, Pekka Abrahamsson
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 90%
Last extracted: 8/5/2026, 4:12:24 AM
Summary
The paper presents the design, implementation, and governance framework of the 'AI Sandbox', a multi-tenant, industry-academia collaboration platform. It addresses the need for secure, compliant AI experimentation by integrating technical architecture (container-based, microservices) with strict governance policies (GDPR, EU AI Act). The report details the MVP deployment on the CSC Rahti cloud, covering requirements analysis, stakeholder consultation, data management, and operational workflows for researchers and industrial partners.
Entities (14)
Relation Signals (12)
AI Sandbox → complieswith → GDPR
confidence 95% · demonstrating compliance with the GDPR, the EU AI Act
AI Sandbox → complieswith → EU AI Act
confidence 95% · demonstrating compliance with the GDPR, the EU AI Act
AI Sandbox → deployedon → CSC Rahti
confidence 92% · Implementation and deployment of a functional MVP on the CSC Rahti cloud platform.
Pekka Abrahamsson → authored → AI Sandbox
confidence 90% · Authors ... and Pekka Abrahamsson
Muhammad Waseem → authored → AI Sandbox
confidence 90% · Authors Muhammad Waseem... Technical Report AI Sandbox
GPT Lab → developed → AI Sandbox
confidence 90% · The GPT-Lab highlighted the importance of traceability... responsible for LLM evaluation, architecture design
Tampere University → hosts → GPT Lab
confidence 90% · Affiliation GPT Lab, Faculty of Information Technology and Communication Sciences Tampere University
AI Sandbox → usesdatafrom → Avoindata.fi
confidence 88% · These sources include national portals such as Avoindata.fi
AI Sandbox → →
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Collaborative AI experimentation across industry and academia requires platforms that enable rapid prototyping while preserving controlled access, tenant separation, and transparent workflows. Despite growing interest in AI sandboxes, there is still limited practical guidance on how to design and implement platforms that integrate experimentation capabilities with governance requirements. This work presents the design and implementation of a governance-aware, multi-tenant AI sandbox for structured experimentation and the generation of reusable evaluation evidence across projects and stakeholder groups. The sandbox was developed within an industry-academia collaboration based on requirements that were iteratively refined with industrial partners. Its reference architecture separates the multi-tenant user interface from the backend control plane and places execution and data-management functions in dedicated layers. The platform supports governed user onboarding, project-centered collaboration, managed access to AI services, approval workflows, audit logging, and traceable experimentation. Experiment configurations, contextual information, and governance decisions are stored as persistent records, allowing evidence and outcomes to be compared and reused across projects. The development process provides practical lessons for deploying and extending governance-aware AI sandbox platforms in collaborative research and industrial environments.
Tags
Links
- Source: https://arxiv.org/abs/2608.02679v1
- Canonical: https://arxiv.org/abs/2608.02679v1
Trouble viewing inline? Open PDF directly →
Full Text
161,773 characters extracted from source content.
Expand or collapse full text
Technical Report AI Sandbox Authors Muhammad Waseem, Md Aidul Islam, Md Nasir Uddin Shuvo, Md Mahade Hasan, Kai-Kristian Kemell, Jussi Rasku, Mika Saari, Vilma Saari, Roope Pajasmaa, Markku Oivo, and Pekka Abrahamsson Affiliation GPT Lab, Faculty of Information Technology and Communication Sciences Tampere University, Tampere, Finland DIMECC Oy, Tampere, Finland University of Oulu, Oulu, Finland ISBN ISBN 978-952-03-4669-0 (pdf) March 1, 2026 | Version 0.1 | Classification: Public This document is provided for information purposes. Redistribution is permitted only according to the stated classification. arXiv:2608.02679v1 [cs.SE] 2 Aug 2026 Acknowledgements The preparation of this report benefited from generative AI tools used for language polishing, consistency checks, formatting support, and the visualisation of a limited number of figures for improved readability. The final manuscript was reviewed by the authors prior to release. i Revision History Ver.DateAuthor(s) StatusSummary of Changes 0.130 Sep 2025 MW, PADraftInitial draft including system re- quirements, preliminary architec- ture definition, and baseline gover- nance and policy framework for the GPT Lab Sandbox. 0.920 Jan 2026MW, PAInternal Review Terminology consolidation; up- dates to governance and security sections; refinement of MVP defi- nition and deployment documenta- tion for CSC Rahti environment. 1.003March 2026 MW, PARelease Final reviewed and approved re- lease version. Architecture dia- grams validated; references cross- checked; formatting and structural consistency finalized for publica- tion. Note: All changes are documented in accordance with the internal quality assurance procedures of GPT Lab. i Executive Summary Artificial intelligence development is increasingly constrained by regulatory, security, and data-governance requirements. Organisations must innovate rapidly while demonstrating compliance with the GDPR, the EU AI Act, and emerging cybersecurity obligations. How- ever, trusted environments that combine experimentation speed with governance-by-design remain limited. This report presents the design and implementation of the AI Sandbox for Industry– Academia Collaboration: a secure, transparent, and compliance-ready platform enabling controlled AI experimentation across organisational boundaries. The Sandbox integrates technical architecture, governance mechanisms, and operational policies into a unified and auditable environment. Scope of Work. The project comprised: • Structured stakeholder-driven requirements analysis; • Design of a modular, container-based system architecture; • Development of a governance and policy framework aligned with European regulation; • Implementation and deployment of a functional MVP on the CSC Rahti cloud platform. Key Outcomes. • Validated Requirements Framework: Prioritised functional and non-functional require- ments addressing data sensitivity, localisation constraints, security, and regulatory com- pliance. • Modular Architecture: A scalable, interoperable, and container-based design compris- ing orchestration, AI service layers, data management, and protection mechanisms. • Governance-by-Design Model: Clearly defined organisational roles, access control poli- cies, audit mechanisms, and compliance procedures aligned with GDPR and the EU AI Act. • Operational MVP Deployment: A working prototype demonstrating secure access control and managed experimentation workflows. The Sandbox establishes a standards-aligned infrastructure where governance, compliance, and technical capability are integrated by design rather than applied retrospectively. i Contents Acknowledgementsi Revision Historyii Executive Summaryiii 1 Introduction1 1.1 Purpose of the Document . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Background and Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.3 Importance of Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.4 Stakeholder Consultations . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.5 System Prototype Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.6 Collaboration and Onboarding . . . . . . . . . . . . . . . . . . . . . . . . 3 1.7 Compliance and Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.8 Positioning and Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2 Requirements and Data Analysis5 2.1 Consultation Process and Stakeholders . . . . . . . . . . . . . . . . . . . . 5 2.2 Data and Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.1 Data management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2.2 Onboarding, Access & Collaboration Workflows . . . . . . . . . . 8 2.2.3 System & Administration Features . . . . . . . . . . . . . . . . . . 10 2.2.4 AI Services Features . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.5 Demonstration of Model Usage . . . . . . . . . . . . . . . . . . . . 15 2.2.6 Hardware Management Features . . . . . . . . . . . . . . . . . . . 16 3 Architecture and Technology Stack18 3.1 Architecture and Key Components . . . . . . . . . . . . . . . . . . . . . . 18 3.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.1.2 Architectural Style and Principles . . . . . . . . . . . . . . . . . . . 18 3.1.3 Layers and Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.1.4 Implemented Prototype Footprint . . . . . . . . . . . . . . . . . . 21 3.2 Security and Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.3 Data Flow and Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.4 Deployment Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.5 Performance and Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.6 Monitoring and Observability . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.7 Technology Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4 Governance and Policy Framework32 4.1 Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 iv AI Sandbox for Industry–Academia CollaborationContents 4.1.1 Operating Model and Neutrality . . . . . . . . . . . . . . . . . . . 32 4.1.2 Roles, Responsibilities, and RACI . . . . . . . . . . . . . . . . . . . 34 4.1.3 Access and Resource Governance . . . . . . . . . . . . . . . . . . . 35 4.1.4 Data Governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.1.5 IP and Licensing Policy . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.1.6 Compliance and Assurance . . . . . . . . . . . . . . . . . . . . . . 42 4.1.7 Security Baseline and Incident Response . . . . . . . . . . . . . . . 44 4.1.8 Change Control, Versioning, and Exit Strategy . . . . . . . . . . . 47 4.1.9 Implementation Link: Policy↔ Technology . . . . . . . . . . . . . 47 4.2 Glossary of Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 5 AI Sandbox MVP49 5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 5.2 System Architecture and Key Components . . . . . . . . . . . . . . . . . 49 5.3 User Interface Demonstration . . . . . . . . . . . . . . . . . . . . . . . . . 50 5.3.1 Landing Page and Access Gateway . . . . . . . . . . . . . . . . . . 50 5.3.2 Academic and Research Hub . . . . . . . . . . . . . . . . . . . . . 50 5.3.3 Company Hub and Collaboration Environment . . . . . . . . . . . 51 5.3.4 System Dashboard and User Management . . . . . . . . . . . . . . 52 5.3.5 Hardware and Resource Management . . . . . . . . . . . . . . . . 53 5.3.6 AI Services and Model Evaluation . . . . . . . . . . . . . . . . . . 55 5.3.7 LLM Comparison and Benchmarking (One example) . . . . . . . 55 5.4 Repository and Documentation Access . . . . . . . . . . . . . . . . . . . . 56 5.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 6 Frequently Asked Questions58 7 Conclusions61 v List of Figures 3.1 AI Sandbox high-level architecture . . . . . . . . . . . . . . . . . . . . . . 19 3.2 Security and Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.3 Data Flow & Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.4 Deployment Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.5 Performance & Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.6 Monitoring & Observability . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.1 Proposed Operating Model . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.2 Data governance framework . . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.3 Intellectual Property (IP) and Licensing Policy . . . . . . . . . . . . . . . 41 4.4 Compliance and assurance framework . . . . . . . . . . . . . . . . . . . . 43 5.1 Landing page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 5.2 Academic Hub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 5.3 Company Hub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 5.4 System dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 5.5 Hardware Management Interface . . . . . . . . . . . . . . . . . . . . . . . 54 5.6 AI Services module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.7 Model benchmarking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 vi List of Tables 1.1 Thematic areas of the Sandbox . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1 Summary of Data Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2 Onboarding, Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.3 Analysed Summary of System & Administration Features . . . . . . . . . 12 2.4 Analysed Summary of Use Cases for the AI Sandbox . . . . . . . . . . . . 15 2.5 Summary of Open and Semi-Open AI Models . . . . . . . . . . . . . . . . 16 2.6 Hardware Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.1 Technology Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.1 Illustrative RACI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.2 Indicative Allocation Tiers and Service Levels by Role . . . . . . . . . . . 36 4.3 Summary of Security Baseline and Incident Response Measures . . . . . 47 4.4 Security and Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 vii Introduction Highlights • Purpose of the Sandbox and this document • Motivation and importance of secure industry–academia collaboration • Prototype overview and demonstration of feasibility • Thematic service areas of the Sandbox • Stakeholders, onboarding processes, and collaboration flows • Built-in compliance, monitoring, and security mechanisms • Positioning of the Sandbox as a Minimum Viable Product (MVP) 1.1 Purpose of the Document This document introduces the AI Sandbox, a secure yet shared environment where companies, universities, research institutes, and public organisations can collaborate on research and development. The current version has been demonstrated as a prototype, showing the feasibility and value of such an environment. The purpose of this report is to document the work completed so far, present the results from the prototype, and establish a foundation for the next phase of development. While the prototype illustrates the main features and structure, the system will evolve based on feedback, new requirements, and future investments. 1.2 Background and Motivation There is a growing need for a trusted environment where industry and academia can safely experiment with AI, machine learning, and software engineering tools [60, 22]. Many organisations face difficulties in testing AI-driven solutions due to security, compliance, or cost constraints. Similarly, universities require practical ways to transfer research outputs into industrial practice. The AI Sandbox addresses these needs by combining a secure technical setup with clear governance and thematic services. It lowers barriers for experimentation and collaboration while ensuring compliance with Finnish regulations, the EU AI Act, and GDPR [21, 19, 27, 20]. 1 AI Sandbox for Industry–Academia CollaborationIntroduction 1.3 Importance of Collaboration The Sandbox is built on the principle that innovation cannot happen in isolation [13, 2]. Companies, universities, research institutes, and public organisations each hold expertise needed to develop trustworthy and effective solutions. • Companies contribute domain knowledge, practical problems, and pathways to scale. • Universities and research institutes provide cutting-edge methods, critical eval- uation, and training of new talent. • Public organisations ensure solutions align with societal needs, regulation, and public trust. By creating a shared and secure space for these groups, the Sandbox maximises their strengths. It accelerates innovation, reduces risks by providing a controlled environ- ment, and ensures outcomes meet both industrial and societal expectations. 1.4 Stakeholder Consultations The design has been informed by direct input from: • Three external company representatives, including SMEs and industrial stake- holders. • The GPT-Lab research team at Tampere University. • Bi-weekly meetings with consortium representatives. Their feedback was consolidated into six thematic areas that form the logical backbone of the Sandbox services (see Table 1.1). ThemeFocusExample Features Research & Develop- ment Controlled experimentation, reproducibility, benchmarking [65, 1, 69] Results dashboards, curated datasets, experiment tracking AI & Machine LearningModel training, automation, evaluationText analysis, computer vision, speech processing, fine-tuning workflows Templates & WorkflowsReady-made processes for industry and academia Project templates, domain-specific workflows, au- tomated pipelines Security & Compliance [39, 38, 51] Trust, neutrality, regulatory adherenceGDPR dashboards, EU AI Act readiness, vulnera- bility scanning Infrastructure & Re- sources Scalable technical foundationGPU management, orchestration, secure data stor- age, automated testing Collaboration & Man- agement Organisational and human collaborationProject tracking, resource sharing, collaboration analytics, scheduling Table 1.1: Thematic areas of the Sandbox, derived from consultations. 1.5 System Prototype Overview The prototype demonstrates the Sandbox as a multi-tenant platform with a rich set of administrative and user-facing capabilities. Core features include: 2 AI Sandbox for Industry–Academia CollaborationIntroduction • A System Admin Console for global platform administration, with live health monitoring of CPU, memory, storage, and network usage, as well as real-time activity dashboards for users and services. • User management tools for adding, approving, and monitoring roles such as researchers, students, and administrators, ensuring secure collaboration with clear responsibilities [64]. • Organisation management functionality, where universities, research institutes, and companies are registered as tenants, each with its own members and project environments. • A Service management interface that enables administrators to deploy, configure, and monitor services such as the AI Services Platform, Data Catalog, Collaboration Hub, Analytics Dashboard, Security & Compliance service, and Model Training Service. • Multi-tenant awareness, shown in the distribution of roles (researchers, students, administrators) and services (AI, data, analytics, security, collaboration). Together, these features illustrate a working backbone for experimentation and collab- oration that integrates technical control, compliance, and scalability. 1.6 Collaboration and Onboarding Collaboration and onboarding are central to the Sandbox vision: • Company onboarding: Organisations can register profiles, contribute resources, and access compliance-ready infrastructure. • Academic onboarding: Researchers join via the Academic Hub, use project tem- plates, and share results in controlled formats. • Collaboration matching: Smart search and AI-powered recommendations enable discovery of partners and launch of projects. • Shared experimentation: Teams jointly access secure execution environments while safeguarding data and compliance. 1.7 Compliance and Security Even as a prototype, compliance and data protection have been built in: • Multi-tenant isolation at organisation, project, and service levels. • Role-based access control and user approval workflows. • Audit logging of administrative actions and service usage. • Security & compliance services with GDPR and EU AI Act monitoring. These features ensure that while the environment is shared, each tenant’s data and experiments remain secure. 3 AI Sandbox for Industry–Academia CollaborationIntroduction 1.8 Positioning and Value The AI Sandbox, in its prototype form, functions as a Minimum Viable Product (MVP). It demonstrates end-to-end workflows: from organisation onboarding to user and service management, experimentation, and compliance monitoring. Looking ahead, it will evolve into a fully operational environment that supports larger- scale pilots, long-term collaborations, and Nordic–Baltic initiatives. The prototype has provided the necessary proof to take these next steps and invest in a secure, collaborative, and future-ready innovation platform. 4 Requirements and Data Analysis Highlights • Requirements elicited through structured consultations with Bittium, Q4US, Solita, DIMECC, and Tampere University GPT-Lab • Prioritised use cases capturing real-world value for SMEs, industry, and academia • Functional requirements covering AI services, user management, data handling, collaboration, and compliance • Non-functional requirements addressing security, scalability, usability, neutral- ity, and legal compliance • Domain-specific needs for healthcare, public services, and manufacturing • AI Service Catalogue of 41 services grouped into five categories • Requirement prioritisation and traceability to guide MVP, advanced, and strate- gic phases 2.1 Consultation Process and Stakeholders The requirements for the AI Sandbox were identified through a systematic and iterative consultation process that combined interviews, workshops, prototype reviews, and sprint demonstrations [36]. The process was designed to capture both short-term needs related to the Minimum Viable Product (MVP) and longer-term requirements for scaling the platform into a more mature, enterprise-ready environment. Consultation Approach • Structured Interviews: One-on-one sessions of 30–45 minutes were conducted with company representatives and research partners to collect detailed functional and non-functional requirements. • Sprint Reviews: At the end of development sprints, prototype features were demonstrated and feedback was gathered from stakeholders to refine require- ments. • Bi-weekly Consortium Meetings: Regular meetings ensured that academic, in- dustrial, and coordination partners were aligned and that requirements evolved in response to feedback. • Evidence Collection: Requirements were traced against artefacts, including proto- type snapshots (e.g., admin console, user/organisation management) and system feature documentation [36]. 5 AI Sandbox for Industry–Academia CollaborationRequirements and Data Analysis Participating Organisations The following organisations contributed actively to the requirements gathering process: • Bittium: A Finnish technology company specialising in secure communications and mission-critical software systems. Bittium emphasised the importance of tenant isolation, compliance with security standards, and reliable benchmarking frameworks for AI models. • Q4US: A software engineering SME with a focus on applied AI solutions and early adoption of new technologies. Q4US committed to testing the sandbox MVP and stressed the need for cost estimation tools, benchmarking templates, and automated testing support. • Solita: A digital transformation company with expertise in data engineering, cloud platforms, and AI-driven services. Solita highlighted the importance of data governance, anonymisation, and the ability to integrate domain-specific datasets in compliance with country-specific laws. • DIMECC: Serving as the facilitator of the consortium, DIMECC provided coordi- nation, ensured neutrality, and represented broader industrial engagement. Their input focused on governance, sustainability, and adoption models. • Tampere University GPT-Lab: The academic research partner responsible for LLM evaluation, architecture design, and alignment with EU AI Act and related standards. The GPT-Lab highlighted the importance of traceability, compliance monitoring, and reproducible experimentation. Key Findings The consultations revealed several recurring requirements that cut across different stakeholder groups: • A secure sandbox environment that enables experimentation without risking pro- duction systems. • Benchmarking and estimation tools to help SMEs evaluate competitiveness and predict project costs. • GDPR-compliant data handling, including anonymisation and data residency con- trols, to facilitate safe use of sensitive datasets [19]. • A multi-tenant, collaborative platform that allows companies, universities, and public organisations to run projects together while maintaining data isolation [50, 45]. • Support for alignment with the EU AI Act, including risk assessment and ongoing monitoring [21]. 2.2 Data and Requirements This section outlines the core requirements and data foundations of the AI Sandbox. It describes how open and domain-specific datasets are accessed, cleaned, and used for AI experimentation under GDPR and EU AI Act considerations. It then presents the onboarding and collaboration workflows, system and administration features, AI 6 AI Sandbox for Industry–Academia CollaborationRequirements and Data Analysis services, and hardware management capabilities. Together, these elements link stake- holder needs to datasets, workflows, and platform services, providing a baseline for future expansion. 2.2.1 Data management We have collected a range of open and domain-specific data sources that can be used within the AI Sandbox to support research, testing, and fine-tuning activities. These sources include national portals such as Avoindata.fi, Statistics Finland, and THL’s Sotkanet database, as well as European-level resources such as the EU Open Data Portal [10, 66, 28, 16]. In addition, specialised archives like Findata and the Finnish Social Science Data Archive (FSD) provide controlled access to sensitive healthcare and social datasets, enabling experimentation under strict compliance safeguards [26, 29]. The purpose of using these datasets is to provide researchers, companies, and public organisations with representative and compliant data that supports use cases ranging from benchmarking and domain adaptation to compliance testing and service innovation. Within the sandbox environment, data can be accessed through APIs or direct downloads, preprocessed via pipelines for cleaning and anonymisation, and then integrated into AI workflows for training, fine-tuning, or evaluation. A consolidated summary of the identified data sources and their relevance to sandbox use cases is provided in the following table. Table 2.1: Summary of Data Sources SourceDomainPurpose / Use CaseAccessibility Avoindata.fi (Finland’s Open Data Portal) Public services, munici- palities Provides open datasets on government services, municipal operations, infras- tructure, and demographics for AI-based public service innovation. Open access via API and downloads Statistics Finland (Tilas- tokeskus) Demographics, econ- omy, society Statistical datasets on population, labour, economy, and social indicators for bench- marking and model evaluation. Open access, bulk down- loads THL Sotkanet Database (Finnish Institute for Health and Welfare) Healthcare, welfareNational indicators on healthcare, wel- fare, and wellbeing, enabling health- related AI experiments under compli- ance safeguards. Open API access Findata (Health and So- cial Data Permit Author- ity) Sensitive healthcare and social data Controlled access to individual-level reg- ister data for advanced health research and domain-specific fine-tuning. Permit-based, regulated access Finnish Social Science Data Archive (FSD) Surveys, social research Provides curated datasets from surveys and studies, supporting domain-specific experimentation in public and social ser- vices. Open or restricted de- pending on dataset EU Open Data Portal (data.europa.eu) Cross-domain, EU-wide Aggregates European datasets across governance, economy, environment, and policy for multilingual and cross-border AI use cases. Open access via API and downloads ELIXIR Finland / CSC Re- sources ELIXIR [12, 6] Life sciences, biomedi- cal research Offers domain-specific datasets and bioinformatics resources for healthcare- related AI experiments and model vali- dation. Access via research col- laboration agreements 7 AI Sandbox for Industry–Academia CollaborationRequirements and Data Analysis 2.2.2 Onboarding, Access & Collaboration Workflows The AI Sandbox implements structured workflows that ensure smooth entry for univer- sities, companies, and individual researchers, while also supporting their collaborative activities once onboarded. Each workflow provides tailored access paths, compliance enforcement, and role-based resource allocation, ensuring that participants can join and collaborate securely and efficiently. 1. Universities & Research Institutes Onboarding: Provides a dedicated academic hub where universities, faculties, and research groups can manage projects, col- laborate with students, and handle research data. Includes publication support and structured onboarding paths for different types of academic users. Ensures that research activities are compliant, secure, and well-documented. 2. Companies & Organisations Onboarding: Enables corporate registration with support for R&D collaboration, innovation projects, and technology transfer. Or- ganisations can set up profiles, manage resources, and coordinate projects with academic partners. Compliance and governance features ensure corporate partic- ipation meets regulatory and industry requirements. 3. Individual Researchers Onboarding: Provides independent researchers, consul- tants, and visiting scholars with a streamlined onboarding path. Enables partic- ipation in research projects, applications for roles, and professional networking opportunities. Ensures individuals can contribute meaningfully without requir- ing institutional backing. 4. Collaboration Categories: Once onboarded, users can collaborate through struc- tured categories: Company to Company, University to University, Company to University, Individual to Company, Individual to University, and Individual to Individual/Others. Each category provides workflows for project creation, part- nerships, and knowledge exchange, enabling flexible yet governed collaborations across stakeholder types. 5. Self-Service Registration: Allows users to register directly via the landing page with email verification, role selection, and organisation assignment. Reduces entry barriers while maintaining structured access for different user types. Approval workflows adapt to role sensitivity to ensure proper governance. 6. Role-Specific Entry Points: Guides each user type through tailored onboarding routes (academic, corporate, or independent). Aligns the onboarding process with role expectations to prevent misuse and provide clarity. Automates compliance and resource allocation based on user type. 7. Free Trial Access: Offers a 14-day trial period without financial commitments, lowering barriers for new users. Builds trust with prospective organisations by allowing them to explore the platform risk-free. Encourages experimentation and adoption at an early stage. 8. Compliance-Aware Access: Embeds GDPR, EU AI Act, and Finnish regulatory requirements directly into the onboarding process. Classifies users according to compliance obligations and tailors access accordingly [19, 21]. Ensures legal requirements are addressed from the start of the user journey. 8 AI Sandbox for Industry–Academia CollaborationRequirements and Data Analysis 9. Approval Workflow Integration: Balances accessibility with governance by au- tomating low-risk approvals while requiring manual checks for sensitive roles. Supports multi-level organisational approval chains with escalation where needed. Provides oversight for high-privilege accounts and sensitive operations. 10. Authentication Controls: Employs JWT-based authentication, strong password policies, and multi-factor authentication for secure login. Session management ensures identities are safeguarded throughout usage. Forms the foundation of secure access for all users [42, 52]. 11. Personalised Dashboards: Directs users to dashboards tailored to their role, sub- scription tier, and resource allocation once onboarding is complete. Provides immediate access to relevant tools and data, reducing friction during adoption. Enhances productivity from the first login by contextualising the user experience. Analysis of Onboarding, Access & Collaboration Workflows The following table provides a consolidated analysis of the onboarding and access features in the AI Sandbox. These workflows define how different types of users (uni- versities, companies, and individuals) join the platform, gain access, and collaborate with others. Each feature has been evaluated in terms of its value, expected outcome, target domain, and implementation priority. 9 AI Sandbox for Industry–Academia CollaborationRequirements and Data Analysis Table 2.2: Onboarding, Access & Collaboration Workflows in the AI Sandbox #Workflow FeatureValue / OutcomeDomainPriority 1Universities & Research Insti- tutes Onboarding Dedicated academic hub with project management, student collaboration tools, research data handling, and publication support Academia, research in- stitutes High 2Companies & Organisations On- boarding Corporate registration with support for R&D projects, technology transfer, and innovation partnerships Industry, R&D teamsHigh 3Individual Researchers On- boarding Streamlined onboarding for consultants, postdocs, and independent researchers with project participation and network- ing tools Freelance, academic vis- itors Medium 4Collaboration CategoriesStructured models for Company↔ Com- pany, University↔ University, Company ↔ University, and Individual↔ others, enabling flexible partnerships Cross-domain collabora- tion High 5Self-Service RegistrationDirect registration with email verifica- tion, organisation assignment, and role selection to reduce entry barriers All usersHigh 6Role-Specific Entry PointsTailored onboarding routes (academic, corporate, individual) ensuring clarity, compliance, and resource alignment All domainsHigh 7Free Trial Access14-day trial period to lower barriers for adoption and build trust with organisa- tions before commitment All prospective usersMedium 8Compliance-Aware AccessGDPR/EU AI Act aligned onboarding with user classification, consent, and data residency enforcement Academia,industry, public sector High 9Approval Workflow Integration Automated low-risk approvals with man- ual checks for sensitive roles and multi- level organisational chains All governance levelsHigh 10Authentication ControlsSecure login with JWT, password poli- cies, MFA, and session management to safeguard identities All domainsHigh 11Personalised DashboardsRole-based dashboards ensuring imme- diate access to relevant tools, projects, and data after onboarding All usersHigh 2.2.3 System & Administration Features The AI Sandbox includes a comprehensive set of system and administration features that support secure and compliant management of users, organisations, and resources. These features form the governance and operational backbone of the platform, sup- porting multi-tenant collaboration while maintaining alignment with EU regulations. 1. Multi-Layer Access Control System: Combines authentication, authorisation, organisation-based management, and permissions. Ensures secure access to ser- vices, governance, and role-specific control across the sandbox. 2. User Registration and Onboarding: Provides self-registration with email verifi- cation, role selection, and organisation assignment. Includes approval workflows and status tracking for pending, approved, rejected, or suspended users. 3. User Status Management: Manages the lifecycle of user accounts with clear status transitions. Allows administrators to monitor and adjust access as needed to maintain operational integrity. 10 AI Sandbox for Industry–Academia CollaborationRequirements and Data Analysis 4. Advanced User Profile Management: Maintains user profiles with personal in- formation, research areas, subscription tiers, and quota allocations. Supports role assignment, permission inheritance, and activity audit trails. 5. Role-Based Access Control (RBAC): Implements a seven-level hierarchy from super administrators to external stakeholders. Enforces least-privilege access and fine-grained permission control [64]. 6. Multi-Tenant Organisation Management: Enables creation and administration of isolated organisations with their own policies. Provides resource quotas, com- pliance settings, subscription management, and organisation-level analytics dash- boards. 7. Dynamic Resource Management and Quotas: Allocates CPU, GPU, storage, and API resources with monitoring. Supports allocation, adjustments, usage reporting, and quota reset cycles for fairness and efficiency. 8. Audit and Compliance Logging: Captures user actions, system events, security incidents, and data access. Supports GDPR and EU AI Act requirements through evidence collection, lineage tracking, and compliance reporting. 9. Administrative Dashboard: Provides a console for user management, approvals, monitoring, and compliance checks. Includes metrics, security dashboards, re- source monitoring, and performance analytics. 10. Approval Workflows: Manages approvals for onboarding, resource requests, quota increases, and project creation. Supports escalation rules and organisation- specific approval chains. 11. Advanced Security Controls: Provides security controls including JWT-based au- thentication, MFA, encryption in transit and at rest, and strong password policies. Enforces least-privilege principles with permissions and access revocation. 12. System Analytics and Reporting: Delivers usage insights, cost analysis, per- formance trends, and collaboration metrics. Generates compliance reports and supports optimisation of system operations. 13. Scalability and Performance Management: Supports performance through dis- tributed architecture, horizontal scaling, caching, and database optimisation. Sup- ports growth in user bases and workloads. 14. Customisation and Extensibility: Allows role creation, workflow configuration, and organisation-specific policy settings. Provides integration APIs and a plugin approach for extending platform capabilities. 15. User Experience and Accessibility: Delivers an intuitive and responsive interface with role-specific views. Supports mobile access, updates, and WCAG-aligned accessibility for inclusive usage across user groups. Analyses of System & Administration Features The following table provides an analysed summary of the system and administration features implemented in the AI Sandbox. Each feature is described in terms of its value, outcome, and relevance to different domains, together with its priority for implementation. This supports a structured view of governance, compliance, and operational requirements within the platform. 11 AI Sandbox for Industry–Academia CollaborationRequirements and Data Analysis Table 2.3: Analysed Summary of System & Administration Features #FeatureValue / OutcomeDomainPriority 1Multi-Layer Access Control System Provides secure authentication, autho- risation, and organisation-based gover- nance with permissions for controlled ac- cess. All users and adminis- trators High 2User Registration & Onboard- ing Supports self-registration, email verifica- tion, role selection, and organisation as- signment with approval workflows. AllHigh 3User Status ManagementManages account lifecycles (pending, ap- proved, rejected, suspended) ensuring controlled access. AllHigh 4Advanced User Profile Man- agement Maintains user profiles, subscription tiers, quota allocation, and audit trails for accountability. Researchers, administra- tors High 5Role-Based Access Control (RBAC) Implements a seven-level role hierarchy from administrators to external stake- holders, enforcing least-privilege princi- ples. AllHigh 6Multi-TenantOrganisation Management Enables isolated organisations with quo- tas, compliance settings, subscription tiers, and analytics dashboards. Universities, companies High 7Dynamic Resource Manage- ment & Quotas Allocates CPU, GPU, storage, and API limits with monitoring, adjustments, and reset cycles. Research projects, SMEs High 8Audit & Compliance Logging Logs user actions, system events, and data access. Supports GDPR and EU AI Act compliance reporting. Administrators, audi- tors High 9Administrative DashboardProvides a console for user management, approvals, monitoring, and compliance checks with metrics. AdministratorsHigh 10Approval WorkflowsOffers approvals for onboarding, re- source allocation, and sensitive opera- tions with escalation rules. Organisations, adminis- trators High 11Advanced Security ControlsEnsures security via JWT, MFA, encryp- tion, permissions, and access revocation. AllHigh 12System Analytics & Reporting Delivers usage insights, cost analysis, performance trends, and compliance re- ports. Admins, managersMedium 13Scalability & Performance Management Supports distributed architecture, hori- zontal scaling, caching, and optimised databases for reliability. All organisationsHigh 14Customisation & Extensibility Allows role creation, workflow configu- ration, and plugin-based extensions. Administrators, part- ners Medium 15User Experience & Accessibil- ity Provides intuitive design with WCAG alignment and mobile-ready access for users. All end usersHigh 2.2.4 AI Services Features Based on the consultations, workshops, and internal R&D discussions, we have com- piled an initial set of features for the AI Sandbox. These features represent a structured translation of stakeholder requirements into concrete services. They are not consid- ered final; instead, they form a baseline that will evolve as more companies and public organisations join the initiative and contribute additional domain-specific needs. The current feature set covers benchmarking, experimentation, core AI services, infras- tructure, and compliance. Each feature is briefly described below. 12 AI Sandbox for Industry–Academia CollaborationRequirements and Data Analysis 1. Model Benchmarking Service: Provides standardised templates and automated pipelines for model evaluation. Enables SMEs and research groups to benchmark models against datasets and generate comparative reports. 2. Requirement Templates Generation Service: Supports transformation of unstruc- tured requirements into structured, compliance-ready formats. Improves consis- tency, reduces manual effort, and helps identify missing information. 3. Cost Estimation Service: Produces cost and resource estimates for projects. Offers breakdowns of compute, storage, and effort requirements to support budgeting and proposal preparation. 4. AI Technique Assessment Service: Recommends appropriate AI/ML techniques based on project requirements and available data. Provides guidance for selecting suitable algorithms and workflows. 5. Data Preprocessing Service: Supports data cleaning, transformation, and feature engineering. Includes quality reporting to support preparation of datasets for experimentation. 6. Controlled Experiment Execution Service: Supports reproducible and secure execution of experiments. Integrates GPU allocation, monitoring, and version control for traceability. 7. Results Dashboard and Reporting Service: Provides dashboards and compar- ative analysis of results. Supports exportable reporting for documentation and decision-making. 8. Text Analysis Service: Provides natural language processing tools such as senti- ment analysis, classification, and entity recognition. Supports anonymisation and secure processing for sensitive data. 9. Computer Vision Service: Offers image classification, object detection, and recog- nition capabilities. Supports privacy-preserving methods and bias analysis for responsible use. 10. Retrieval-Augmented Generation (RAG) Service: Enhances document intelli- gence through retrieval combined with generation. Supports Q&A, search, and summarisation with citation tracking. 11. Fine-Tuning Service: Enables domain-specific adaptation of AI models with mon- itoring. Supports customisation of pre-trained models. 12. Speech Processing Service: Provides speech-to-text, text-to-speech, and voice analytics. Supports transcription and synthesis. 13. Recommendation Service: Implements personalised recommendations using collaborative, content-based, and hybrid methods. Supports privacy through anonymisation and access controls. 14. Time Series Analysis Service: Provides forecasting, trend analysis, and anomaly detection for time-dependent data. Supports use cases for finance, manufacturing, and energy. 15. Anomaly Detection Service: Detects irregular patterns in structured and un- structured data streams. Uses statistical, ML, and deep learning techniques with alerting. 13 AI Sandbox for Industry–Academia CollaborationRequirements and Data Analysis 16. LLM Playground Service: Offers an environment to experiment with large lan- guage models. Supports text, code, and interactive analysis tasks. 17. GPU Resource Allocation Service: Provides on-demand access to GPU resources with allocation and workload monitoring features. 18. Secure Data Storage Service: Provides encrypted storage aligned with EU data residency requirements. Integrates access control and audit logging for security and traceability. 19. Experiment Tracking Service: Manages the lifecycle of experiments through ver- sion control and parameter logging. Supports reproducibility and long-term R&D tracking. 20. AI Model Vulnerability Scanning Service: Scans models and datasets for vulner- abilities, bias, and compliance risks [23, 51]. Produces reports and remediation guidance. 21. Legal Assistant Service: Provides conversational support related to GDPR and EU AI Act compliance. Supports risk assessment and documentation tasks. 22. Data Residency Control Service: Allows organisations to manage data storage locations to comply with jurisdictional requirements. Provides monitoring and reporting. 23. Data Anonymization Service: Applies anonymisation techniques such as k- anonymity, l-diversity, and t-closeness. Supports GDPR-aligned use of sensitive data while preserving utility [67, 47, 46]. 24. AI-Native Anomaly Detection Service: Extends anomaly detection with AI/ML and optional LLM integration. Supports monitoring across multiple data types with alerts. 25. Compliance Auditing Service: Supports GDPR and EU AI Act compliance checks. Integrates evidence collection, reporting, and risk assessment. 26. AI Security Scanning Service: Provides scanning of code, dependencies, and infrastructure. Offers remediation advice to strengthen system security. Analyses of AI Services Features The following table summarises the initial set of AI features identified for the AI Sand- box through stakeholder consultations, prototype reviews, and internal brainstorming. Each use case highlights a concrete organisational need, its value, and priority across domains. These represent a baseline portfolio that will evolve as more organisations join and contribute additional requirements. 14 AI Sandbox for Industry–Academia CollaborationRequirements and Data Analysis Table 2.4: Analysed Summary of Use Cases for the AI Sandbox #Use Case / ServiceValue / OutcomeDomainPriority 1Model Benchmarking ServiceCompare SME-trained models against industry standards to measure competitiveness Cross-domainHigh 2Requirement Templates Generation Service Transform unstructured requirements into structured, compliance-ready documentation Software engineering, IT ser- vices High 3Cost Estimation ServiceProvide transparent pricing and effort estimation for project proposals using AI analysis IT servicesMedium 4AI Technique Assessment ServiceRecommend suitable AI/ML methods and approaches for specific business or research needs Cross-domainHigh 5Data Preprocessing ServiceEnable automated, standardised, and high-quality prepa- ration of datasets for experiments AllHigh 6Controlled Experiment Execution Ser- vice Ensure reproducible, secure, and monitored execution of experiments with GPU allocation Research and industry R&DHigh 7Results Dashboard and Reporting Ser- vice Provide dashboards for monitoring, comparison, and ex- porting results AllHigh 8Text Analysis ServicePerform NLP including sentiment analysis, classification, and entity recognition Knowledge-intensive servicesMedium 9Computer Vision ServiceSupport image classification, detection, and recognition with privacy protection Manufacturing, healthcare, secu- rity Medium 10Retrieval-Augmented Generation Ser- vice Deliver Q&A and document intelligence with citationsKnowledge-intensive servicesMedium 11Fine-Tuning ServiceCustomise AI models with hyperparameter tuning work- flows AI research, SMEsMedium 12Speech Processing ServiceProvide speech-to-text and text-to-speech with multilin- gual support Public services, education, me- dia Medium 13Recommendation ServiceEnable personalised recommendations for digital plat- forms with privacy controls E-commerce, mediaMedium 14Time Series Analysis ServiceForecast trends and detect anomalies in time-dependent data Finance, manufacturing, energyHigh 15Anomaly Detection ServiceProvide anomaly detection for structured and unstruc- tured data Cross-domainHigh 16LLM Playground ServiceOffer an environment for testing large language models across tasks Research, education, SMEsHigh 17GPU Resource Allocation ServiceProvide GPU resources for scalable AI training and infer- ence Research, SMEs, IT servicesHigh 18Secure Data Storage ServiceEnsure encrypted, EU-aligned data storage with access controls AllHigh 19Experiment Tracking ServiceSupport reproducibility with experiment tracking and comparison Research and innovation projects High 20AI Model Vulnerability Scanning Ser- vice Identify vulnerabilities and biases in models and training data AllHigh 21Legal Assistant ServiceProvide guidance on GDPR and EU AI Act compliance and related documentation AllHigh 22Data Residency Control ServiceManage data storage locations to meet jurisdictional re- quirements AllMedium 23Data Anonymization ServiceSupport GDPR-aligned use of sensitive datasets through anonymisation Healthcare, public servicesHigh 24AI-Native Anomaly Detection Service Monitor heterogeneous data streams with AI/LLM inte- gration options Critical infrastructure, financeHigh 25Compliance Auditing ServiceSupport GDPR and EU AI Act checks with evidence man- agement AllHigh 26AI Security Scanning ServiceConduct vulnerability scanning across code, infrastruc- ture, and runtime AllHigh 2.2.5 Demonstration of Model Usage In addition to analysing the openness and licensing aspects, we also demonstrated how these models could be integrated within the AI Sandbox environment for different purposes, including text generation, code assistance, and image-related tasks. The demonstrations showcased workflows for model selection, execution, and monitoring in a secure and compliant sandbox setting. It is important to note that, due to the scope and requirements of this project, these models were not implemented as production-ready services. Instead, the demonstra- tions were designed to illustrate feasibility, integration workflows, and the potential value for future expansion of the sandbox platform. 15 AI Sandbox for Industry–Academia CollaborationRequirements and Data Analysis Table 2.5: Summary of Open and Semi-Open AI Models Model / ProjectOrigin / MaintainerLicense TypeOpenness LevelNotes Falcon 40BTII (UAE)Apache 2.0Fully OpenFirst large-scale model released with full openness. Falcon 7BTII (UAE)Apache 2.0Fully OpenEfficient lightweight variant for smaller tasks. BLOOM / BLOOM 2BigScience / Hugging FaceRAILOpen weights + data (restricted use) Multilingual with transparent training data. GPT-J 3.5EleutherAIApache 2.0Fully OpenGPT-3 class model with strong adoption. GPT-NeoX-20BEleutherAIApache 2.0Fully OpenLarge-scale transformer, widely used. YaLM-100BYandexApache 2.0Fully Open100B bilingual model (Russian/English). UL2 / Flan-UL2GoogleApache 2.0Fully OpenInstruction-tuned, T5-style architecture. Cerebras-GPTCerebrasApache 2.0Fully OpenTransparent family of GPT models. StableLMStability AIApache 2.0Fully OpenOpen-source focus on chat/instruction. MPT (7B, 30B)MosaicMLApache 2.0Fully OpenModular, efficient, long-context models. RedPajama / INCITETogether AI + partnersApache 2.0Fully OpenOpen reproduction of LLaMA dataset. OpenLLaMAOpenLM ResearchApache 2.0Fully OpenLLaMA reproduction with open data. XGen-7BSalesforceApache 2.0Fully OpenEfficient transformer for long context. Jais-13BInception Institute UAEApache 2.0Fully OpenArabic-centric with open weights. OpenHermesTeknium / communityMITFully OpenCommunity-driven, chat-focused model. Dolly 3.0DatabricksMITFully OpenInstruction-tuned for enterprise tasks. PolyLM (1.7B, 13B)Shanghai AI LabApache 2.0Fully OpenMultilingual, with Asian-language focus. LLaMA 3Meta AICustom (R/C)Weights onlyPowerful but restricted licensing. VicunaLMSYS (LLaMA fine-tune)Non-commercialWeights onlyPopular for chat, non-commercial license. Mistral 7B v2Mistral AIApache 2.0Weights only (closed data)Small, efficient, high quality. Gemma 2.0 FlashGoogle DeepMindCustom permissiveWeights onlyLightweight, efficient model. DeepSeek-R1DeepSeek AICustomWeights onlyBilingual, Chinese/English focused. Baichuan 2 (7B, 13B)Baichuan AICustomWeights onlyStrong Chinese-language model. ChatGLMTsinghua / ZhipuAIApache 2.0Weights onlyWidely used bilingual Chinese model. Grok AIxAI (Elon Musk)UnknownUnclearMarketed as open, not yet released. 2.2.6 Hardware Management Features The hardware management feature module in the AI Sandbox provides structured access to computational resources that are essential for AI development, including large language model training, fine-tuning, and inference. It ensures that researchers and companies can request, schedule, and monitor hardware usage with transparency in pricing, compliance, and approval processes. The following features define how resources are provisioned, optimised, and governed within the sandbox. 1. HPC Resource Management: Provides access to high-performance GPU and CPU clusters (e.g., NVIDIA A100/H100 GPUs and AMD EPYC CPUs) with detailed specifications, availability, and transparent per-hour costs. Supports model train- ing, large-scale inference, and data-intensive AI workflows. 2. Storage Resource Management: Offers high-capacity and high-speed storage systems for AI datasets and experiment outputs. Enables secure, redundant, and scalable data management with parallel file systems and object storage, ensuring smooth handling of large training corpora. 3. Cloud Resource Integration: Connects to Kubernetes clusters across AWS, Azure, and GCP, supporting containerised AI workloads. Supports deployment for train- ing, fine-tuning, and distributed inference while maintaining EU compliance [44]. 4. Request Creation Workflow: Implements a guided multi-step wizard for selecting hardware, scheduling usage, and providing justification. Includes cost calculation and ensures that requests are tied to approved AI research projects. 5. Approval Workflows: Supports multi-level administrative approvals for resource requests. Validates availability, budget allocations, and organisational policies before granting access to GPUs or compute clusters. 16 AI Sandbox for Industry–Academia CollaborationRequirements and Data Analysis 6. User Resource Dashboard: Provides role-based dashboards with status of hard- ware availability, utilisation metrics, and cost estimates. Supports monitoring of GPU/CPU usage. 7. Monitoring and Analytics: Tracks utilisation, experiment throughput, and per- project costs. Supports usage optimisation, bottleneck identification, and capacity planning for AI experiments. 8. Security and Compliance Controls: Embeds GDPR compliance, EU AI Act align- ment, role-based access, encrypted storage, and audit trails. Ensures secure and legally compliant use of AI-related resources. 9. Advanced Scheduling: Enables calendar-based bookings, recurring GPU reserva- tions, and priority queues for urgent experiments. Supports conflict handling to support fair access and utilisation. 10. Optimisation Features: Provides recommendations for load balancing, energy efficiency, and cost minimisation. Supports organisations in managing compute usage across AI research and development. 11. Integration APIs: Offers REST APIs, webhooks, and SDKs for integrating hard- ware management with external AI pipelines, monitoring systems, and billing tools. Supports automation and integration into existing research workflows. Analysis The Hardware Management Module ensures that the AI Sandbox can deliver secure, scalable, and transparent access to computational resources needed for AI and large language model development. It integrates GPU/CPU allocation, storage, cloud in- tegration, scheduling, and monitoring into one governed environment, enabling or- ganisations to manage costs, optimise performance, and remain compliant with EU requirements. Table 2.6 summarises the analysed features of this module. Table 2.6: Analysed Hardware Management Features for the AI Sandbox #FeatureValue / OutcomeDomainPriority 1HPC Resource ManagementProvides high-performance GPU/CPU clusters for training, fine-tuning, and inference with transparent costs and avail- ability. Research, AI development, SMEs High 2Storage Resource ManagementEnsures scalable, redundant storage for large datasets and experiment outputs with high-speed access. Data-intensive AI projectsHigh 3Cloud Resource IntegrationEnables Kubernetes deployments (AWS, Azure, GCP) for distributed AI workloads with EU compliance. Cross-domain AI researchMedium 4Request Creation WorkflowGuides users through hardware request and cost estimation tied to project needs. AllHigh 5Approval WorkflowsValidates resource requests via multi-level admin approval to enforce governance and fair access. Research and organisa- tional IT High 6User Resource DashboardProvides visibility into resource usage, availability, and costs. AllHigh 7Monitoring & AnalyticsTracks utilisation, throughput, and costs for optimisation, planning, and performance improvements. Research and R&D infras- tructure High 8Security & Compliance ControlsEmbeds GDPR and EU AI Act compliance with encryption, access logs, and audit trails [50]. All (legal and regulatory)High 9Advanced SchedulingOffers calendar-based bookings, recurring reservations, and priority queuing to optimise utilisation. Cross-domainMedium 10Optimisation FeaturesProvides recommendations for cost savings, energy effi- ciency, and balanced utilisation. AllMedium 11Integration APIsProvides APIs and SDKs for integrating hardware manage- ment with AI pipelines and billing systems. Research, IT servicesMedium 17 Architecture and Technology Stack Highlights • Layered and modular architecture of the Sandbox • Secure design with built-in privacy and compliance features • Data flow, integrations, and control mechanisms • Container-based deployment and scalability path • Monitoring, observability, and performance readiness Overview This part of the deliverable defines the sandbox’s high-level architecture and the tech- nology stack that enables secure, compliant AI experimentation. It specifies the sys- tem’s key components and interfaces, the deployment model, and the mechanisms that ensure privacy, security, and regulatory alignment (GDPR and EU AI Act). The content is kept practical and implementation-oriented to reflect the current prototype. 3.1 Architecture and Key Components 3.1.1 Overview The AI Sandbox prototype was implemented using a layered and microservices-based (MSA) architecture [32, 31, 30]. Each layer has a defined responsibility and interacts with neighbouring layers through stable APIs. This combination supports modularity, scalability, and maintainability, and it is realised in the working demo. Figure 3.1 provides the structural view. User roles interact with the frontend appli- cation (Next.js, React/TypeScript, Tailwind CSS, JWT-based authentication) [68, 48]. The frontend communicates with backend microservices (Express.js on Node.js) that expose REST APIs [56, 25, 24]. These services orchestrate AI capabilities such as anomaly detection, preprocessing pipelines, security scanning, compliance auditing, and an LLM playground. All interactions are governed by a data and security layer that enforces encryption, access control (RBAC and ABAC), tenant isolation, and audit logging. 3.1.2 Architectural Style and Principles The prototype follows a layered model and an MSA style in parallel: • Layered modularity: Clear separation of frontend, backend services, AI services, and data/security. 18 AI Sandbox for Industry–Academia CollaborationArchitecture and Technology Stack Hugging Face API OpenAI API AI Providers Avoindata.fi Statistics Finland Data Sources Logs + Traces Dashboards Observability Tracing CSC/Fairdata Findata FSD Login/signup, users onboarding. approve/reject users Admin & Governance API Org management, roles, audit linkage Collaboration & Projects API Projects, collaboration spaces User Acces & Identity API Model Evaluation Metrics, Token, Time & Other Output Model Fine Tuning Fine Tuned Model File (GGUF / Safetensor), Adaptar, Weights Model Registry Hosted Model Access & Evaluation Model Inference & Evaluator Authentication Middleware (JWT + RBAC + ABAC) AI Execution Layer Frontend Layer (Multi-Tenant ) Researchers, Educators, Industry Users, System Admins Security & Compliance JWT Authentication RBAC /ABAC Tenant Isolation TLS Encryption Log, Trace DataUser History SQLite Project recordsMetadata PostgreSQL Monitors Academic HubCompany Hub Features Core UI Modules Admin & Governance Manage (User, Org, Hardware, Services, Projects, Roles), Audit, Projects Project (Create, Update, Maintain), Browse Authentication Login, Signup, Logout, Profile Role-aware navigation (RBAC/ABAC-driven visibility) Hardware Allocation Data Management Data (Sources, Processing, Integration, Compliance) AI Services Cataglog Services (Discover, Request, Access)Manage & allocate VRAM, CPU, GPU Collaboration Hub Al & Experiments API LLM promot experimentation, experiments, model requests/ services, experiments Microservices Gateway (Discovery + Proxy) Individual microservices module for each service Backend Layer • High availability • Concurrency - Traces (planned) • Backup & Scaling • High Reliability • ACID Compliance Data & Storage Layer GDPR Controls EU AI Act Readiness Figure 3.1: AI Sandbox high-level architecture with layered design and microservices-based components. • Microservices orientation: Independentservices communicate over REST (/api/auth, /api/projects, /api/ai-services, /api/hardware, etc.). • Cloud-native: Containerised services with a migration path from Docker Com- pose (prototype) to Kubernetes (production). • Security by design: TLS 1.2+ (TLS 1.3 preferred), AES-256 at rest, RBAC/ABAC [64, 33], MFA where required, tenant isolation, and continuous audit trails [63, 9, 49]. • Compliance integration: GDPR and EU AI Act guardrails embedded in work- flows; alignment with Finnish regulations (Findata, THL, FSD) when applicable. • Role-centric UX: Dashboards tailored for Super Admin, Research Admin, Re- searchers, University Faculty, and Company Admins. • Scalability and extensibility: Horizontal scaling, database migration from SQLite to PostgreSQL, and pluggable AI service integrations. 3.1.3 Layers and Interfaces The following sublayers and interfaces make the architecture operational. Each de- scription links the user-facing needs to the underlying services and controls. User Interface Role-specific portals reflect permissions and tasks. • Landing and Authentication: Entry point, login, registration, session handling. 19 AI Sandbox for Industry–Academia CollaborationArchitecture and Technology Stack • Dashboards: Personalised views for students, researchers, and companies with notifications and quick access to services. • AI Services Catalogue: Browse and request access to registered services (more than 24 available in scope during prototyping, with a broader catalogue defined in the requirements chapter). • Admin Console: Configure services, monitor usage, manage users, and enforce policies. Backend and Microservices Stateless services expose stable REST APIs and enforce access policies. • Authentication and Authorisation: JWT and JOSE for tokens, RBAC/ABAC checks, optional MFA [42, 41, 43, 40]. • Core APIs: /api/auth, /api/users, /api/projects, /api/ai-services (cata- logue, execute, results), /api/hardware (requests and approvals). • Operational Services: Access request workflow, admin management, file upload, notifications. Data and Storage Persistent stores and data utilities support projects and auditability. • Prototype store: SQLite for low-ops persistence with fast bindings. • Production target: PostgreSQL for concurrency, migrations, backup, and high availability. • Core entities: Users and roles, projects, AI services, hardware requests, audit logs, notifications, file metadata. Security and Compliance Controls are applied at every boundary and recorded for audit. • Access control: RBAC and ABAC with least privilege and separation of duties. • Protection measures: TLS 1.2+ in transit (TLS 1.3 preferred), AES-256 at rest, input validation, rate limiting, security headers. • Compliance: GDPR mechanisms (consent, subject rights, DPIA, breach notifica- tion), EU AI Act readiness (risk classification, human oversight, transparency), and national guidelines where relevant. • Monitoring and evidence: Immutable audit logs, health checks, and operational metrics. External Integrations The platform connects to AI providers and public data sources through controlled interfaces. 20 AI Sandbox for Industry–Academia CollaborationArchitecture and Technology Stack • AI providers: Hugging Face API, OpenAI API, and custom services for anomaly detection, preprocessing, security scanning, and compliance auditing. • Data sources: Avoindata.fi, Statistics Finland, THL Sotkanet, Findata, FSD, EU Open Data Portal, ELIXIR, and CSC resources as applicable. • Support services: Email notifications, file storage backends, analytics, and moni- toring endpoints. 3.1.4 Implemented Prototype Footprint The demo validates the architecture in a realistic setup and defines a clear route to production. • Frontend: Next.js 14.2.5 with React/TypeScript and Tailwind CSS, running on port 3000. • Backend: Express.js on Node.js 18+, running on port 3001, exposing the control plane and AI service endpoints. • Persistence: SQLite in the prototype with a planned migration to PostgreSQL in production. • AI services: Anomaly detection, data preprocessing pipelines, security scanner, compliance auditor, and LLM playground, orchestrated through the backend APIs. • Security: JWT-based authentication, RBAC and ABAC, tenant isolation, audit logging, and input validation. • Deployment path: Docker and Docker Compose in development and staging, with Kubernetes and PostgreSQL as production targets [44, 45, 11]. 3.2 Security and Compliance Security and compliance operate as a cross-cutting layer over the architecture in Fig- ure 3.1. Figure 3.2 summarises the control set implemented in the prototype: (i) Authentication & Authorisation, (i) Data Protection & Privacy, (i) Compliance Alignment, (iv) Security Monitoring & Audit, and (v) Observations/Outcomes. These controls are exercised along the request path described in Figure 3.3—from the UI, through service APIs, to data stores and external providers—and are evidenced by audit logs, consent records, and configuration policies. Figure 3.2: Security and Compliance: control families applied across layers and interfaces (AI-assisted illustration). 21 AI Sandbox for Industry–Academia CollaborationArchitecture and Technology Stack Authentication & Authorisation (left block in Figure 3.2) • JWT/JOSE: Signed (JWS) and, where required, encrypted (JWE) tokens; short- lived access tokens with refresh [42, 41, 43, 40, 64, 33]. • RBAC: Role-based permissions aligned with system roles (student, researcher, company, organisation admin, system admin). • ABAC: Attribute rules (e.g., organisation, project, dataset class) for fine-grained policies. • MFA: Prompts for privileged actions (admin configuration, dataset upload/approval). • Least Privilege & Separation of Duties: Requesters cannot approve their own access; services run with minimal scopes. Data Protection & Privacy (second block) • Encryption in Transit: TLS 1.3 (fallback to 1.2 only if necessary) for client↔service and service↔service traffic. • Encryption at Rest: AES-256 for databases and backups; keys retained within EUEEA jurisdictions [63, 9, 49]. • Anonymisation/Pseudonymisation: GDPR-aligned techniques for PII before non- production use or cross-tenant sharing. • Consent Management: Explicit consent for uploads/sharing with verifiable, time- stamped records. • Data Residency Control: Policies and storage classes that enforce regional location requirements. Compliance Alignment (centre block) • GDPR by Design: Subject access/erasure workflows, purpose limitation, data minimisation, comprehensive auditability. • EU AI Act Preparedness: Service risk classification (minimal/limited/high), human-oversight checkpoints, robustness testing, transparency artefacts. • Documentation & Transparency: Model/dataset metadata, decision logs, config- uration snapshots, usage histories retained for audits. • National Guidance (Finland): Alignment with Findata/THL/FSD for health and social-science datasets where applicable. Security Monitoring & Audit (fourth block) • Audit Logging: Immutable, time-stamped records of user and system actions; cryptographically verifiable where required. • Intrusion/Anomaly Detection: Alerts for unusual authentication patterns, API misuse, and denial-of-service attempts. • Incident Response: Playbooks for detection, escalation, containment, recovery, and post-incident review. • Protective Controls: Rate limiting, schema-based input validation, and secure headers to mitigate common web threats. 22 AI Sandbox for Industry–Academia CollaborationArchitecture and Technology Stack 3.3 Data Flow and Integration Building on the control families in Section 3.2 and the structural view in Figure 3.1, this section shows where those controls are exercised along the request path. Figure 3.3 summarises the data-flow and integration view and should be read together with the security overlay in Figure 3.2. Primary Request–Response Cycle The core cycle has eight stages; each stage cites the principal control(s) applied: 1. User Request: A user initiates an action via the frontend (e.g., login, project update, AI service execution). Entry checks: input validation and basic rate limiting. 2. Authentication: The request passes through JWT/JOSE middleware for token vali- dation and session management; MFA is prompted for privileged actions. Controls: TLS 1.3, short-lived tokens with refresh. 3. Authorisation: RBAC/ABAC verifies that the caller has the privileges required for the requested action. Controls: least privilege and separation of duties. 4. Business Logic: The backend service applies workflow rules (e.g., access request approval, service execution parameters) and records decisions. Controls: struc- tured audit events. 5. Data Access: Validated queries execute against the database. Controls: encryption at rest (AES-256), residency policies, consent/anonymisation where applicable, immutable audit logs. 6. External Integration: When required, the service calls third-party APIs (e.g., Hugging Face, OpenAI) in a controlled and logged manner. Controls: outbound allow-lists, scoped tokens/keys, provider SLAs/DPA alignment, latency/error monitoring. 7. Response: The service returns a structured result (JSON/HTML) to the frontend. Controls: data minimisation, appropriate cache headers. 8. Notification: The system emits user notifications (email/dashboard) and opera- tional/audit events. Controls: signed events and retention policies. API Integration Points The platform uses well-defined interfaces for internal and external communication: • Internal REST APIs: Dashboards communicate with microservices via stable end- points (/api/auth, /api/users, /api/projects, /api/ai-services, /api/hardware). • Database Access Layer: Secure, abstracted access to SQLite in the prototype and PostgreSQL in production; migrations and audit hooks included. • External AI APIs: Hugging Face and OpenAI for model access and execution, called through gateway functions with scoped credentials. • Notification APIs: Email and alerting services to surface important system events to users and admins [34, 35, 54]. 23 AI Sandbox for Industry–Academia CollaborationArchitecture and Technology Stack Integration with External Services Third-party services are integrated with explicit guardrails: • Hugging Face API: Access and deploy pre-trained models within scoped rate limits and logs. • OpenAI API: GPT-based LLM capabilities via audited requests; optional EU- hosted endpoints when required. • Monitoring Services: Metrics and error rates for observability across external calls. • File Storage Services: Secure handling of user datasets with presigned access and retention controls. Observations • Traceability: Requests are traceable end-to-end via structured audit events and logs. • Defence in Depth: Authentication, authorisation, validation, and encryption ap- pear at multiple stages. • Integration Readiness: Standard APIs enable interaction with external providers without weakening compliance. • Scalable Flows: The modular design supports parallel requests and external calls, with clear points for caching and back-pressure. Figure 3.3: Data Flow and Integration across stages and interfaces (to be read with Figures 3.1 and 3.2). (AI-assisted illustration) 3.4 Deployment Architecture Following the controls in Section 3.2 and the request path in Figure 3.3, this section describes where the system runs and how it is packaged, configured, and promoted across environments. Figure 3.4 summarises the baseline deployment model that was used for the prototype and the planned path to production. Containerisation All frontend, backend, and supporting services are packaged as containers to keep build and runtime consistent: 24 AI Sandbox for Industry–Academia CollaborationArchitecture and Technology Stack • Docker images: Multi-stage builds produce small, reproducible images for the Next.js frontend and Express-based services. • Stateless services: Containers are designed to be stateless; persistent state is kept in the database or object storage, simplifying scaling and failover. • Configuration profiles: Separate compose files and environment files for develop- ment, staging, and production ensure predictable rollouts. Database Deployment The data layer follows a clear prototype-to-production migration path: • Prototype: SQLite3 for lightweight local persistence without a dedicated server. • Production target: PostgreSQL(or equivalent) for concurrency, migrations, backup/restore, and high availability. • Schema management: Version-controlled migrations are applied as part of the release pipeline to keep environments aligned. • Backup strategy: Automated backups with recurrent recovery tests to verify re- store procedures. Security Deployment Security controls from Section 3.2 are enforced at runtime: • TLS everywhere: TLS 1.3 for all client–service and service–service traffic; certifi- cates managed per environment. • Secrets management: In the prototype, environment variables are used with rotation; production adopts a secrets manager (cloud KMS/Vault) and scoped service identities. • Network segmentation: Frontend, services, and databases are placed on separate networks/VPC segments with strict inbound/outbound rules. • Access control: Admin panels and APIs require authenticated, authorised access; audit events are shipped to central logs as part of the deployment. Environments The system is promoted through three stages, keeping configuration and evidence consistent: • Development: Local containerised setup with debug tools, seeded data, and permissive logging to speed iteration. • Staging: Mirrors production topology with anonymised datasets for pre-release testing and performance checks. • Production: Hardened environment with strict policies, high availability targets, and continuous compliance monitoring. Observations This deployment approach supports the architectural goals: 25 AI Sandbox for Industry–Academia CollaborationArchitecture and Technology Stack • Prototype simplicity: Fast iteration with Docker and SQLite, aligned with the flows in Figure 3.3. • Scalability readiness: Defined migration paths to PostgreSQL and Kubernetes for multi-service scaling. • Built-in security: TLS, segmented networks, and secret handling reflect the con- trol set in Section 3.2. • Consistency: Reproducible builds and environment-specific profiles reduce drift and increase confidence in releases. Figure 3.4: Deployment Architecture across development, staging, and production (to be read with Figures 3.1 and 3.3). 3.5 Performance and Scalability Building on the runtime model in Section 3.4 and the request path in Figure 3.3, this section describes how the prototype achieves low latency today and how it scales to production. Figure 3.5 groups the main levers applied at the API, data, and delivery layers. Performance Optimisation The system applies practical techniques to reduce latency and stabilise throughput: • Database indexing: Targeted indexes speed up common lookups (e.g., users, projects, access requests). • Connection pooling: Reuses DB connections to avoid setup overhead under bursty load (especially after migrating from SQLite to PostgreSQL). • Caching strategy: Caches frequently accessed data (service metadata, session context) to reduce round trips. • API design: REST endpoints use clear HTTP semantics, compact JSON, pagina- tion, and conditional requests (ETag/If-None-Match) where applicable [25, 24]. • Asynchronous processing: Moves non-critical work (email, log shipping, report generation) off the request path. • Asset optimisation: Tree-shaking and code-splitting in Next.js, gzip/brotli com- pression, and long-lived cache headers for static assets. Scalability Considerations The architecture scales horizontally first, with clear paths for stateful services: 26 AI Sandbox for Industry–Academia CollaborationArchitecture and Technology Stack • Horizontal scaling: Frontend and backend run as multiple container replicas behind a load balancer. • Database migration path: SQLite (prototype) to PostgreSQL (production) for concurrency, transactions, and HA. • Load balancing: Reverse proxydistributes traffic evenly and supports zero-downtime rollouts. • CDN: Static assets (JS/CSS/images) are served via a content delivery network to cut latency. • Elastic scaling: Kubernetes orchestration allows autoscaling and pod reschedul- ing as demand changes. • Queues & cache (when needed): Redis for sessions/caching and a lightweight queue (e.g., RabbitMQ/NATS) for background jobs. Target Service Levels While still a prototype, we define measurable objectives to guide tuning and capacity planning: • Response time:< 200 ms at the 95th percentile for typical API calls under normal load. • Concurrent users: 100+ concurrent users demonstrated in prototype; production target≥ 1,000 concurrent sessions. • Workflow latency: Benchmarking, anonymisation, and similar jobs complete within SLA thresholds (seconds to minutes, depending on payload). Observations • The prototype delivers responsive behaviour on lightweight infrastructure through indexing, caching, and async work. • Scaling focuses on horizontal replication and migration to enterprise-grade databases, with Kubernetes enabling elastic capacity. • CDN delivery and controlled rollouts (Section 3.4) prepare the system for produc- tion and regional expansion. Figure 3.5: Performance levers and scalability path (read with Figures 3.3 and 3.4). (AI-assisted illustration) 27 AI Sandbox for Industry–Academia CollaborationArchitecture and Technology Stack 3.6 Monitoring and Observability Building on the runtime model in Section 3.4 and the request path in Figure 3.3, this section explains how the prototype is instrumented for reliability, trust, and compliance. Instrumentation spans APIs, data stores, infrastructure, and external integrations, with evidence captured for the control set in Section 3.2. Figure 3.6 provides the overview. System Monitoring The platform monitors key resources and services to ensure availability and perfor- mance: • Application metrics: Response times, error rates, and throughput for backend services. • Database monitoring: Query latency, connection-pool utilisation, and storage growth. • Resource usage: CPU, memory, container health, and node capacity to prevent saturation. • External-service monitoring: Latency and error responses for Hugging Face and OpenAI calls to detect integration failures early. Logging and Audit Trails Structured logging and audit trails provide traceability and compliance evidence (see Section 3.2): • Structured logs: JSON-formatted logs from all services for parsing and correla- tion. • Audit logs: Immutable records of user actions (logins, uploads, service requests) for forensic analysis. • Error tracking: Centralised capture of exceptions and failure events for debugging. • Security logging: Signals for suspicious logins, denied access, and abuse patterns. Observability Tools Operational visibility is delivered through dashboards, alerts, and traces: • Dashboards: Real-time views of SLIs/SLOs for service health and capacity. • Alerts: Policy-driven notifications for SLA breaches, downtime, and anomalies. • Tracing: Distributed traces connect frontend requests to backend and database operations. • Compliance dashboards: Summaries of GDPR and EU AI Act obligations (con- sent, access/erasure requests, audit completeness). Incident Response Workflow The system follows predefined steps to handle incidents end to end: 1. Detection through monitoring or alert. 28 AI Sandbox for Industry–Academia CollaborationArchitecture and Technology Stack 2. Automatic escalation to system administrators. 3. Containment of the affected service or environment. 4. Resolution via runbooks with change records. 5. Post-incident review to improve controls and prevent recurrence. Observations • Transparency: Significant events are logged and auditable across the request path in Figure 3.3. • Reliability: Proactive alerts reduce time to detect and time to recover. • Compliance: Logs and dashboards provide evidence for GDPR and EU AI Act requirements. • Continuous improvement: Incident reviews feed upgrades to deployment and security controls (Sections 3.4 and 3.2). Figure 3.6: Monitoring and observability across metrics, logs, traces, and compliance views (read with Figures 3.3 and 3.4) (AI-assisted illustration). 3.7 Technology Stack Table 3.1 summarises the stack used in the demo prototype, grouped by frontend, backend, data layer, containers/orchestration, security/compliance, integrations, and operations/CI/CD. Each row lists the tool and version, its role, a production-readiness signal (Ready ̄ ready; Conditional = usable with conditions), and practical alterna- tives. To move beyond the prototype: keep Express or switch to Fastify/NestJS for higher throughput; migrate SQLite to PostgreSQL and add Redis plus a queue as workloads grow; retain JWT/JOSE but add OIDC and a secret manager; standardise observability on OpenTelemetry with Prometheus/Grafana, ELK/OpenSearch, and Sentry; adopt Kubernetes (or start with a managed PaaS) [57, 58, 62]; and add an EU-hosted inference gateway (vLLM/TGI) for the AI layer. Typical migration steps are SQLite→PostgreSQL, Docker Compose→Kubernetes, JWT→OIDC/SSO, and ba- sic logs→OpenTelemetry/Prometheus/ELK. 29 AI Sandbox for Industry–Academia CollaborationArchitecture and Technology Stack Table 3.1: Technology Stack — production readiness and credible alternatives. Legend: Ready ready, Conditional usable with conditions. CategoryTechnology / ServiceVersionPurpose (what we imple- mented in the demo) ProdAlternatives when scaling / harden- ing Frontend — Core Framework Next.js + React + Type- Script 14.2.5 / 18.3.1 / 5.9.2 SSR/SSG app shell and routing; component model with strong typ- ing across UI and API types. ReadyRemix; SvelteKit; Vue + Nuxt; Astro (islands). Frontend — Runtime Node.js (dev/build)18+Local dev server and build pipeline for Next.js. Ready— Styling & UI Tailwind CSS; Lucide React; Framer Motion; Class Variance Authority; Tailwind Merge; Radix UI (Slider) 3.4.10; 0.451.0; 11.2.12; 0.7.1; 2.6.0; 1.3.6 Utility-first styling, iconography, animations, robust variant patterns, and accessible controls. ReadyMUI; shadcn/ui; Chakra UI. State / Server Cache React Context; TanStack React Query Built-in; 5.48.0 Auth/session prefs and server-state caching with stale-while-revalidate behaviour. ReadyRedux Toolkit (complex global state); Zustand (lightweight). Notifications React Toastify11.0.5User feedback and alert toasts across flows. ReadyNotistack; Radix Toast. Data Visuali- sation Recharts2.15.4Role/usage metrics and service results charts. ConditionalECharts; Vega-Lite; Plotly (heavy interactivity). Frontend Dev Tools PostCSS; Autoprefixer; ESLint 8.4.39; 10.4.19; 8.57.0 CSS post-processing, vendor prefixing, linting and code quality. ReadyBiome (lint/format); Prettier (format). Backend — Core Framework Express.js on Node.js, FastAPI on Python 4.19.2 / 18+ REST APIs for auth, users, projects, AI ser- vices; control-plane endpoints. ReadyFastify (higher perf); NestJS (DI/modular); Spring Boot; .NET Minimal APIs; Go (Fiber/Gin). Backend — Language TypeScript, Python5.4.5Strong typing, DTOs, and runtime validation pairing with Zod. Ready— Auth & Security JSON Web Tokens (json- webtoken); JOSE 9.0.2; 5.2.4 Token-based auth, JWS/JWE; stateless sessions. ReadyOIDC/SSO (Keycloak, Auth0); PASETO tokens. HTTP Secu- rity Helmet.js; express-rate- limit; CORS 7.1.0; 7.3.1; 2.8.5 Security headers, DDoS/request throttling, cross-origin policy. ReadyWAF / API Gateway policies. Input Vali- dation Zod4.0.17Schema validation for request bodies/params. Readyclass-validator (NestJS); Ajv (JSON Schema). Middleware & Util Morgan; Cookie Parser; Express Session; Multer; UUID; Axios 1.10.0; 1.4.7; 1.18.2; 2.0.2; 11.1.0; 1.7.2 HTTP logging; cookies; sessions; uploads; IDs; outbound HTTP client. Readypino (structured logs); bus- boy/formidable (uploads); ky/got (HTTP). Database — Engines SQLite (sqlite3; better- sqlite3; sqlite) 5.1.7; 12.4.1; 5.1.1 Prototype relational store; low-ops single-file DB with fast bindings. ConditionalPostgreSQL (prod target); Cock- roachDB (distributed SQL); MySQL/MariaDB. Database — CSV / ETL fast-csv; csv-parser5.0.5; 3.2.0 Import/export utilities for datasets and results. ReadyApache Arrow; DuckDB for analytics ETL. ORM / Data Access Direct driver + better- sqlite3 —Thin data-access layer for CRUD; simple migra- tions. ConditionalPrisma; Drizzle ORM; TypeORM; Knex (query builder). Caching / Queues —Not required in proto- type. ConditionalRedis (cache/session); RabbitMQ; NATS; Kafka (event streaming). Backend Dev & Build TSX; ts-node-dev; dotenv; ESLint 4.20.5; 2.0.0; 16.4.5; 8.57.0 TS execution, live-reload, env config, linting. ReadySWC/tsx-node; env vaults. Containers & Base Images Docker; Docker Com- pose; node:18-alpine 20.10+; 2.0+; 18-alpine Containerised fron- tend/backend; multi- service dev with Com- pose. ReadyPodman; Buildx/BuildKit; Bazel rules_docker. Continued on next page 30 AI Sandbox for Industry–Academia CollaborationArchitecture and Technology Stack AI Sandbox Technology Stack — continued CategoryTechnology / ServiceVersionPurpose (what we imple- mented in the demo) ProdAlternatives when scaling / harden- ing Container Config Frontend / Backend containers —Ports 3000 (Next.js) and 3001 (Express); isolated service networks. Ready— Orchestration (target) Kubernetes—Production orchestration, scaling, rollouts. ReadyAWS ECS/Fargate; Nomad; Fly.io; Render/Heroku (managed PaaS). Ingress / Load Balancer Nginx—Reverse proxy, TLS termi- nation, basic routing. ReadyTraefik; HAProxy; cloud LBs (ALB/GLB). Network & Governance TLS 1.2+; RBAC/ABAC; tenant isolation —Encrypted transport, least-privilege, multi- tenant boundaries. ReadymTLS (Istio/Linkerd); OPA/Gatekeeper; Zero-Trust patterns. Secrets Man- agement dotenv (env vars)16.4.5Environment-based secrets/config for proto- type. ConditionalHashiCorp Vault; SOPS+KMS; cloud secret managers (AWS/GCP/Azure). Monitoring & Logging Health endpoints; Mor- gan; console logs —Liveness/readiness checks; HTTP and app logs. ConditionalOpenTelemetry; Prometheus+Grafana; ELK/OpenSearch; Sentry (app er- rors). Tracing—Not implemented in prototype. ConditionalJaeger or Tempo (via OpenTelemetry); Honeycomb (managed). AI / ML Integrations Hugging Face API; Ope- nAI API; custom services —Model access (pre- trained); LLM play- ground; anomaly de- tection, preprocessing, security scanning, com- pliance auditor. ReadyInference gateways (vLLM/TGI/Ollama); Bedrock/Azure OpenAI; modal.run (serverless GPU). External Data Sources Avoindata.fi; Statistics Finland; THL Sotkanet; Findata; FSD; EU ODP; ELIXIR; CSC —National/EU datasets and HPC resources inte- grated where applicable. ReadyCountry-specific portals in new re- gions; commercial providers (e.g., Refinitiv). Delivery & CI/CD Next.js build; multi-stage Docker images —Optimised prod images; reproducible builds. ReadyTurborepo/Nx; GitHub Ac- tions/GitLab CI; Argo CD/Flux (GitOps). Edge / CDN —Not used in prototype.ConditionalCloudflare/Akamai/Fastly; Ver- cel/Netlify Edge for SSR/ISR & caching. 31 Governance and Policy Framework Highlights • Purpose and scope of the governance and policy framework • Neutral, transparent, and accountable operating model • Clearly defined roles, responsibilities, and approval processes • Fair access and resource governance across participants • Comprehensive data governance aligned with GDPR and the EU AI Act • Balanced IP, licensing, and collaboration policies • Built-in compliance, assurance, and reporting mechanisms • Security baseline and incident–response procedures • Change control, versioning, and policy–technology linkage 4.1 Purpose and Scope The purpose of this section is to develop a governance and policy framework that will guide how the AI Sandbox is managed and used in practice. The framework is not only meant to set rules but also to create the conditions for trust, transparency, and neutrality across all participating organisations. It describes how responsibilities are shared, how access to resources is granted, and how decisions are made so that the platform remains fair and accountable. The scope of the framework covers all types of participants, including universities, companies, public organisations, and individual researchers. It ensures that their activities within the sandbox are supported by clear policies for data handling, resource allocation, and collaboration. In particular, the framework integrates requirements from the GDPR and the EU AI Act (risk-based obligations), while also addressing intellectual property, data protection, and practical compliance needs [19, 21]. 4.1.1 Operating Model and Neutrality The proposed operating model of the AI Sandbox is designed to guarantee neutrality, transparency, and long-term sustainability. In this section we outline how the sandbox will be governed, who will oversee its operations, and how conflicts and decisions will be managed. The model is intentionally built to avoid vendor lock-in and to ensure that all participating organisations can rely on a fair and transparent platform. • Neutral Operator: We propose that the sandbox should be operated as a neutral entity, for example a consortium, foundation, or university-operated service with a clear neutrality mandate. The operator should avoid vendor lock-in and ensure openness of policies, interfaces, and technical components. The operator handles 32 AI Sandbox for Industry–Academia CollaborationGovernance and Policy Framework Figure 4.1: Proposed Operating Model and Neutrality Structure for the AI Sandbox, with over- sight by the Steering Group, day-to-day administration by a Neutral Operator, and safeguards through policy publication, accountability reporting, and conflict-of-interest management (AI- assisted illustration) day-to-day administration and publishes policy updates and system changes in a transparent and accessible manner. • Steering Group: We propose the establishment of a multi-stakeholder Steering Group composed of representatives from academia, SMEs, larger industry, and the public sector. Its role is to provide strategic oversight, approve major policy changes, and arbitrate disputes. Meetings should be held quarterly, with consen- sus as the primary decision-making approach and majority voting as a fallback. • Conflict of Interest: To ensure fair decision-making, all Steering Group members should be required to declare relevant financial, institutional, or personal interests. In cases where conflicts arise, members must recuse themselves from related deliberations or decisions [59]. This process reduces the risk of biased outcomes and strengthens stakeholder trust in the governance structure. • Accountability & Reporting: We propose that both the operator and the Steering Group issue regular reports documenting decisions, usage statistics, financial expenditures, and compliance audits. These reports should be shared with all stakeholders to maintain transparency, demonstrate fairness in resource allocation, and ensure that the sandbox evolves in line with community needs. 33 AI Sandbox for Industry–Academia CollaborationGovernance and Policy Framework 4.1.2 Roles, Responsibilities, and RACI To operationalise the proposed governance model, we also propose to define clear roles and responsibilities for all participants in the sandbox. While the previous subsection outlined who provides strategic oversight, this section addresses how responsibilities are distributed in day-to-day operations. We adopt a RACI framework 1 (Responsible, Accountable, Consulted, Informed) to make explicit who performs which actions, who provides oversight, and who must be kept informed. This approach supports trans- parency, reduces overlaps, and builds confidence among stakeholders [61]. User Catalogue We propose that the sandbox adopts a comprehensive role catalogue aligned with the extended access control system demonstrated in the prototype. This ensures that aca- demic, corporate, individual, technical, and external actors are formally represented, each with clear responsibilities and access rights. The proposed categories are: • System Roles: Super administrator, research administrator, researcher, viewer. • Institutional Roles: University administrator, coordinator, faculty, researcher, stu- dent. • Corporate Roles: Corporate administrator, manager, researcher, analyst, intern. • Individual Roles: Independent researcher, consultant, postdoc, visiting scholar. • Technical Roles: Data scientist, machine learning engineer, AI researcher, security analyst. • Platform Roles: Platform moderator, support, auditor. • External Roles: Government official, regulatory officer, funding agency, industry partner. The prototype access-control design supports these categories through role-based and attribute-based controls, and is intended to scale as new stakeholder needs emerge. Table 4.1: Illustrative RACI for Key Governance Activities in the AI Sandbox. RACI notation: R = Responsible, A = Accountable, C = Consulted, I = Informed. When A/R appears together, it indicates that the same actor is both Accountable and Responsible for the activity. ActivityPlatform Opera- tor OrgAdmin (Univ/Corp) Admin / PIComplianceSteering Group User onboarding approvalA/RRCCI Dataset ingestion approvalCA/RRCI GPU quota increaseCA/RRCI Project release/sign-offCA/RRCI Policy changes (major)CIICA Incident response (security)CCIA/RI Compliance audit & evidenceCRRAI 1 https://project-management.com/understanding-responsibility-assignment-matrix-raci-matrix/ 34 AI Sandbox for Industry–Academia CollaborationGovernance and Policy Framework Approval Authorities We propose that the RACI framework is supported by structured approval authorities, which balance efficiency with accountability. The model automates low-risk processes while maintaining human oversight where sensitivity or risk is higher: • Onboarding: Low-risk roles (e.g., students, viewers) may be approved automati- cally, while sensitive roles (e.g., corporate administrators, external stakeholders) re- quire review by an Organisation Admin. Research administrators may co-approve onboarding requests within their projects to ensure smooth academic workflows. • Datasets: Organisation Admins are accountable for dataset ingestion, supported by Security/Compliance experts where sensitive or regulated datasets are in- volved. Principal Investigators remain responsible for ensuring scientific justi- fication of dataset use. • Compute Quotas: Requests for increased GPU/CPU allocations should be re- viewed by Organisation Admins, with the Platform Operator consulted to con- firm capacity and Security/Compliance consulted to ensure isolation and data protection requirements are upheld. 4.1.3 Access and Resource Governance To ensure that the AI Sandbox remains both flexible and sustainable, access to resources is governed through a model that balances fairness, scalability, and compliance. Rather than prescribing fixed hardware quotas that may quickly become outdated, the frame- work defines resource classes, allocation tiers, and service levels that can evolve with available capacity and user demand. This approach reflects practices in established research and cloud infrastructures [7, 8]. Project Types We propose that the sandbox supports both shared and private/isolated project environ- ments. Shared projects enable collaborative experimentation, while isolated projects are reserved for sensitive or regulated data scenarios and include stricter logging, au- dit, and access controls. Project type is determined at the onboarding stage and can be adjusted through approval workflows. Resource Classes and Allocation Tiers Resources are allocated in classes, with quotas scaling by role and subscription tier. These include: • Compute: Access to CPU and GPU resources, with allocations ranging from individual fair-share use to organisation-level pools. GPU resources support both training and inference of large language models. • Storage: Tiered storage combining high-performance file systems (for active ex- perimentation), object storage (for datasets and models), and archival storage (for long-term preservation). Redundancy and encryption are mandatory across tiers. 35 AI Sandbox for Industry–Academia CollaborationGovernance and Policy Framework • Cloud/Hybrid: Integration with Kubernetes-based environments (AWS, Azure, GCP, or national providers) for containerised AI workloads. Enables distributed training, hybrid deployment, and portability of workflows. Specific limits (e.g., GPU hours, storage quotas) are defined in the operational SLA and can be revised as infrastructure evolves. All allocations are fully auditable. Table 4.2: Indicative Allocation Tiers and Service Levels by Role Resource / SLAResearcherResearch Admin / PIOrgAdmin (Univ/Corp) Notes / SLA Target Compute (CPU/GPU)Elastic access, fair-share Higher-tieraccess, multi-GPU jobs Org-wide pools with delegated quotas Standard approvals ≤ 48h StorageTiered (working + archive) Extended tier with project datasets Org-levelallocation with flexible scaling Data redundancy + en- cryption Concurrent jobsLimited concurrent jobs Expanded concurrent capacity Org-wide concurrent al- location Fair-share scheduling applied Cloud / Hybrid Access Pre-configuredtem- plates Custom container work- flows Org-level integration with external cloud credits Elastic scaling where available Incident response—Critical security inci- dents handled≤ 24h Audit / ReportingUser-level usage logsProject-level reportsOrg-wide usage and compliance dashboards All logs auditable by op- erator Usage Policies • An acceptable-use policy prohibits misuse of resources, re-identification attempts, or circumvention of security and compliance controls. • All approvals, usage, and cost attributions are logged and reportable per project, providing a transparent audit trail for accountability. • Resource allocations are subject to periodic review to ensure fair access across users and alignment with community priorities. 4.1.4 Data Governance Building on the access and resource controls, we propose a comprehensive data gov- ernance framework that makes lawful basis, residency, approvals, and lifecycle opera- tions explicit for every dataset ingested into the AI Sandbox. The framework is aligned with established regulatory and industry standards, including the GDPR (Articles 6, 9, 26, 28, 32, 35, and 89) and the EU AI Act (Regulation (EU) 2024/1689, with phased application), together with ISO/IEC 27001 and 27701 for information security and pri- vacy management, and ISO/IEC 23894:2023 for AI risk management [19, 21, 38]. It also draws on national guidance from Findata, THL, and the Finnish Social Science Data Archive (FSD) for handling sensitive health and social data. Figure 4.2 illustrates the overall control stack, while the detailed policy below operationalises it. 36 AI Sandbox for Industry–Academia CollaborationGovernance and Policy Framework Figure 4.2: Data governance framework in the AI Sandbox: classes and residency, policies for open/company/inter-company data, lawful bases and DPIA, and platform controls (metadata catalogue, access approvals, encryption, audit logs, lineage, and secure retention). (AI-assisted illustration) Data Classes For governance purposes, all datasets within the AI Sandbox are organised into stan- dardised data classes that build directly on the sources identified in the data manage- ment section. This classification provides a clear link between the origin of the data, the associated legal and contractual requirements, and the technical controls applied in the sandbox. It ensures that policies are applied consistently across heterogeneous sources and that compliance can be enforced through transparent rules. • Public / Open Data: Includes datasets from national and European open data portals such as Avoindata.fi, Statistics Finland, and the EU Open Data Portal. These datasets are subject to open licences (e.g., C BY, C0) that define reuse conditions. They may be broadly used for experimentation and benchmarking, with licence terms recorded in the sandbox metadata catalogue [5, 4]. • Internal / Organisational Data: Refers to datasets contributed by participating organisations (companies, universities, or public bodies). Access is restricted to the owning organisation and named collaborators. A data processing agreement (DPA) or equivalent intra-group policy must be in place, and default residency is within the EU/EEA. • Sensitive Data: Covers data subject to special safeguards, such as health, social, or personal data obtained from Findata, the Finnish Social Science Data Archive (FSD), 37 AI Sandbox for Industry–Academia CollaborationGovernance and Policy Framework the Finnish Institute for Health and Welfare (THL), or biomedical datasets accessed via ELIXIR/CSC. These datasets can only be processed under the authority’s permit or licensing conditions. Secure, isolated workspaces are mandatory, and all exports are subject to disclosure control and review [8]. Roles and Responsibilities (GDPR alignment) Clear assignment of roles and responsibilities is central to accountability under GDPR and the EU AI Act. We propose the following allocation, ensuring that controllers, processors, and compliance officers act in line with their legal duties [19, 21]. • Controller: By default, the organisation that contributes a dataset (company, uni- versity, or public body). For joint projects, the parties may act as joint controllers under GDPR Article 26, with a written allocation of responsibilities [19]. • Processor: The Sandbox Operator acts as a processor for controller datasets, pro- viding the technical and organisational measures required by GDPR Article 28 [19]. • DPO & Security/Compliance: Review data processing agreements, sign off on DPIA requirements under Article 35, and audit compliance evidence [19, 17]. Policies by Source Type Different categories of data require tailored governance rules. The following policies cover open/public datasets, internal company or university data, sensitive datasets, and inter-company data sharing. • Open/Public data (Avoindata.fi, Statistics Finland, EU Open Data Portal): May be used for research and method evaluation subject to the original licence (e.g., C BY/C0). Licences are recorded in the metadata catalogue; redistribution terms and attribution requirements are enforced in outputs. • Internal/Organisational data (company or university): Access is restricted to the owner organisation and named collaborators. A Data Processing Agreement (DPA) or intra-group policy is required; default residency is EU/EEA. • Sensitive data (Findata, FSD/THL, ELIXIR context): Processing follows the orig- inating authority’s permit or conditions. Secure, isolated workspaces are manda- tory; exports require documented disclosure control and permit-compliant review before release. • Inter-company sharing: Disabled by default. Allowed only via a signed Data Sharing Agreement (DSA), per-dataset access lists, and a recorded lawful basis (e.g., contract, consent, public task). High-risk categories trigger a Data Protection Impact Assessment (DPIA) [19, 17]. 38 AI Sandbox for Industry–Academia CollaborationGovernance and Policy Framework Classification and Residency To ensure lawful and consistent handling, all datasets are classified and assigned a default residency. This classification provides the foundation for storage, processing, and cross-border data management rules. • Classes: Public/Open (licence-governed, non-personal), Internal/Organisational (non- public, may include personal data), Sensitive (e.g., health, social, minors, special categories of personal data as per GDPR Article 9). • Residency: Sensitive data are stored and processed in the EU/EEA by default; internal data follow contractual terms; public/open data may be hosted more broadly if licence permits. Residency is declared in metadata and enforced by policy controls [19]. Lawful Bases, Agreements, and DPIA Every dataset must have a documented lawful basis and, where required, supporting agreements or permits. DPIA requirements are triggered in high-risk contexts and must be completed before project activation. • Each dataset is registered with its lawful basis (e.g., consent, public interest/public task, legitimate interest, contract) and linked agreements (DPA/DSA/permit) [19]. • DPIA triggers: health/biometric or other special-category data; large-scale mon- itoring; vulnerable subjects; cross-organisation sharing; high-risk AI use. DPIA outcomes, including mitigations and human-oversight measures, are recorded before project activation [19, 17]. Technical & Operational Controls To make policies enforceable in practice, the sandbox implements technical and oper- ational controls for dataset registration, access approvals, encryption, isolation, and anonymisation. • Dataset registration & metadata: Mandatory metadata catalogue (source, li- cence/permit, controller/processor roles, lawful basis, residency, retention, con- tact, lineage identifiers). • Access approvals: Role-based approvals per dataset; time-bound access grants; per-project access lists; automatic expiry and re-certification. • Isolation & least privilege: Project namespaces, network policies, and storage isolation; secrets management for credentials; audit-ready logs capturing who, what, when, and why. • Protection: Encryption at rest and in transit (AES-256, TLS 1.2+); key management using managed KMS/HSM; integrity checksums on artefacts. • De-identification: Pseudonymisation/anonymisation tooling (e.g., k-anonymity, ℓ-diversity, t-closeness where applicable) with residual-risk notes attached to the dataset record. 39 AI Sandbox for Industry–Academia CollaborationGovernance and Policy Framework Retention, Deletion, and Lineage Retention, deletion, and lineage controls ensure that data is not held longer than necessary and that its lifecycle is auditable end-to-end. This supports both compliance and reproducibility of experiments. • Retention: Defined per project and source terms (e.g., permit end date). Tiered storage may be used for cost control, subject to residency limits. • Deletion & exit: Cryptographic erasure or secure wipe at project closure, with a verifiable certificate of destruction. Model artefacts derived from sensitive data are reviewed for disclosure risk before retention or release. • Lineage: End-to-end lineage maintained (source→ preprocessing→ training/evaluation → outputs) to support reproducibility, audits, and GDPR challenge/appeal rights. 4.1.5 IP and Licensing Policy Intellectual property (IP) and licensing in the AI Sandbox must balance openness, innovation, and legal certainty for all participants. The proposed policy builds on established practices in Finnish and EU collaborative R&D projects and aligns with European and national legal frameworks [18, 14, 15], including the EU Directive on the protection of trade secrets 2 , the EU Intellectual Property Action Plan 3 , Finnish copyright and data rights legislation, and model agreements such as those used in Horizon Europe 4 . The framework ensures that contributors retain their rights, that new results are clearly allocated, and that licensing remains transparent, auditable, and enforceable. Background IP Background IP refers to the rights that participants bring into the sandbox, such as datasets, algorithms, or software. The policy preserves ownership while allowing limited use within projects. • Background IP remains the property of the original licensor or contributor. • Usage rights are granted only to the extent required for the project, under licence terms or data processing agreements (DPAs). • Confidential or trade-secret materials are protected by law and may not be redis- tributed without explicit permission. Foreground IP Foreground IP is generated in sandbox projects, including trained models, source code, and derived datasets. Ownership follows transparent and predictable rules. 2 Directive (EU) 2016/943 on the protection of undisclosed know-how and business information (trade secrets). 3 European Commission, “Making the most of the EU’s innovative potential: An intellectual property action plan to support the EU’s recovery and resilience,” COM(2020) 760 final, November 2020. 4 European Commission, Horizon Europe Model Grant Agreement, 2021. 40 AI Sandbox for Industry–Academia CollaborationGovernance and Policy Framework Figure 4.3: Intellectual Property (IP) and Licensing Policy in the AI Sandbox, showing alloca- tion of background and foreground IP, licensing of tools and deliverables, and enforcement mechanisms aligned with EU and Finnish legal frameworks. (AI-assisted illustration) • Foreground IP is owned by the project sponsor by default, unless otherwise spec- ified in writing. • Joint ownership may be agreed for collaborative R&D, with clear provisions on exploitation, licensing, and revenue sharing. • Academic publications remain with the authors but must acknowledge the sand- box infrastructure. Tools, Components, and Open Source Core sandbox infrastructure is treated as a shared public good to avoid vendor lock-in and ensure long-term neutrality. • Core sandbox tools (platform services, APIs, orchestration scripts) should be re- leased under permissive licences such as Apache-2.0 or MIT. • Project-specific deliverables (e.g., fine-tuned LLMs) remain proprietary unless explicitly released under open-source or open-data terms. • All third-party dependencies are recorded in a Software Bill of Materials (SBOM) to ensure licence compliance and vulnerability management. Licensing and Access Conditions Licensing conditions define how sandbox outputs may be reused across research, in- dustry, and public contexts. • Open/public data reuse follows the original licence terms (e.g., C BY/C0) [5, 4]. • Proprietary results may be licensed bilaterally under sandbox agreements, with different terms for research use versus commercial exploitation. 41 AI Sandbox for Industry–Academia CollaborationGovernance and Policy Framework • All licences are registered in the sandbox metadata catalogue and validated as part of the approval workflow. Dispute Resolution and Enforcement Clear mechanisms are needed to build trust and address conflicts between participants. • Disputes are governed by Finnish law, with mediation preferred and arbitration or court proceedings as fallback mechanisms. • The multi-stakeholder Steering Group may issue non-binding recommendations to preserve neutrality and avoid escalation. • Violations of licence terms may trigger audits, suspension of access, or termination of project participation. 4.1.6 Compliance and Assurance To ensure that the AI Sandbox operates within a legally robust and trustworthy frame- work, we propose a layered compliance and assurance model aligned with the re- quirements of the EU AI Act, the GDPR, Finnish data protection legislation, and established international standards such as ISO/IEC 27001 (information security man- agement) and ISO/IEC 23894:2023 (AI risk management). This framework is designed to provide transparency, verifiable accountability, and confidence for all participating stakeholders [21, 19, 37]. EU AI Act Alignment The sandbox adopts the risk-based approach of the EU AI Act to classify AI systems and apply safeguards proportionate to their risk profile [21]. • Risk classification: All AI projects in the sandbox are registered with a declared risk category (minimal, limited, or high-risk), based on the intended use case, data sensitivity, and potential societal impact. • High-risk controls: Projects flagged as high-risk (e.g., involving biometric data, employment screening, or health-related decision support) must include human oversight checkpoints, expanded logging, robustness testing, and explainability measures before deployment or external release. • Compliance evidence: Documentation of conformity-related artefacts and DPIAs (Data Protection Impact Assessments) are recorded in the sandbox metadata cata- logue and reviewed by security/compliance officers prior to project activation. Evidence and Auditability Trust in the sandbox depends on transparent and verifiable processes for monitoring compliance and demonstrating accountability to regulators and stakeholders. 42 AI Sandbox for Industry–Academia CollaborationGovernance and Policy Framework Figure 4.4: Compliance and assurance framework in the AI Sandbox, showing alignment with the EU AI Act and GDPR through risk classification, human oversight, audit trails, and layered internal/external audits to support accountability and trust (AI-assisted illustration). • Immutable logging: All key events, including approvals, dataset access, training runs, model evaluation, and release decisions, are logged in an immutable and tamper-evident audit trail. • Internal audits: The sandbox operator will perform periodic internal audits of compliance, security, and data protection practices at least twice per year, with findings reported to the Steering Group. • External assurance: Independentthird-party audits or certifications (e.g., ISO/IEC 27001 or national security audits) may be commissioned by the Steering Group to validate compliance and neutrality. • Corrective actions: Non-conformities identified in audits trigger remediation plans with defined timelines, monitored by the compliance function and reported back to stakeholders. Transparency and Reporting Regular reporting strengthens trust and ensures that compliance activities remain visible to all participants. • Stakeholder reports: Quarterly compliance summaries, including risk classifi- cations, audit outcomes, and corrective actions, are circulated to participating organisations. • Regulatory liaison: Where applicable, reports are aligned with the obligations under Finnish Data Protection Authority guidance and relevant EU supervisory bodies. 43 AI Sandbox for Industry–Academia CollaborationGovernance and Policy Framework • Public transparency: Aggregated and anonymised reports (e.g., number of projects by risk class, compliance audit pass rates) may be published on the sandbox portal to demonstrate accountability to the wider ecosystem. 4.1.7 Security Baseline and Incident Response Building on the operating model, RACI, and data governance controls, we propose the following security and incident–response baseline for the AI Sandbox. The baseline is designed to be vendor-neutral and auditable, and aligns with GDPR, the EU AI Act, and widely adopted security standards and guidance [19, 21, 37, 20, 3]. Where possible, the measures reference widely adopted norms (ISO/IEC 27001/27017/27018/27701; CIS Benchmarks; ENISA and NIST SP 800-61 guidance). Identity and Access Management (IAM) We will operate a least-privilege, role/attribute-based model consistent with the role catalogue and RACI. • Federated SSO & MFA: SAML/OIDC federation with home institutions and com- panies; MFA enforced for administrators, dataset uploaders, approvers, and any user with elevated privileges [55, 53]. • Separation of duties: Approval of onboarding, dataset ingestion, and quota changes requires distinct roles; no single user may both request and approve. • Scoped credentials: Short-lived, scoped API tokens; service accounts with mini- mal scopes; quarterly access recertification; automatic expiry and re-approval for time-bound access. • Tenant isolation: Organisation and project workspaces are isolated (RBAC/ABAC, namespace and network policies) with default-deny access between tenants. Data Security and Isolation Controls protect data in use, in transit, and at rest, and respect declared residency. • Encryption: TLS 1.2+ for all connections; AES-256 (or provider equivalent) at rest. Keys handled by a managed KMS/HSM with EU/EEA residency and role-based key usage. • Network controls: Private subnets, security groups, VPC peering policies, private endpoints to storage; egress controls and DLP rules for sensitive projects; workload identity for intra-cluster access. • Secrets management: Central secrets manager; no secrets in code or images; automatic rotation for database/cloud keys. • Workspace isolation: Sensitive projects run in dedicated, hardened clusters/nodes with policy as code (Pod/Node Security, image allow-lists, resource quotas); ex- plicit export gates for artefacts leaving an isolated workspace. • Backups & recovery: Encrypted backups with EU/EEA residency; routine restore testing; defined RPO/RTO targets (see Operational Metrics). 44 AI Sandbox for Industry–Academia CollaborationGovernance and Policy Framework Assurance: Vulnerability & Supply-Chain Management • Vulnerability management: Monthly authenticated scans; critical findings reme- diated within agreed SLOs (e.g., 7 days for critical, 30 days for high). Annual third-party penetration testing. • SBOM & SCA: Software Bill of Materials for all platform components; continuous software-composition analysis for licence and CVE issues; container images built from minimal CIS-hardened bases, signed and verified (e.g., Sigstore). • Change control: Infrastructure-as-Code with peer review; staged rollouts; auto- mated policy checks (OPA/Conftest) before deploy. Incident Response Playbook Our process follows ENISA and NIST SP 800-61 phases and meets GDPR breach- notification timelines [20, 3, 19]. • Detect & triage: Centralised, immutable logs (WORM) and SIEM correlation for auth events, data access, training jobs, and model releases. Severity (S1–S4) classification with 24/7 on-call rotation for S1. • Contain & eradicate: Isolation at tenant/project level; token/key revocation; im- age rollback; malicious artefact quarantining; temporary export blocks for affected datasets/models. • Recover: Verified restore from clean backups; integrity checksums for artefacts; stakeholder communications and service SLO recovery. • Notify: If personal data are implicated, the Controller is supported to assess notification to the authority within 72 h (GDPR Art. 33) and, where necessary, to data subjects (Art. 34) [19]. • Learn: Post-incident review within 10 working days; corrective actions tracked; semi-annual tabletop exercises for data breach and model-misuse scenarios. Addressing Cross-Company Collaboration Concerns The following map shows how the baseline mitigates the most frequent concerns when multiple companies collaborate in a shared LLM sandbox: • (1) Data security & confidentiality: Tenant isolation; RBAC/ABAC; encryption in transit/at rest with EU/EEA key residency; export gates and DLP for sensitive workspaces; dataset-level access lists tied to lawful basis and approvals. • (2) IP ownership: Background/foreground IP and licensing handled per Sec- tion IP and Licensing Policy; artefact provenance (dataset→ training run→ model) recorded to support ownership and attribution. • (3) Model governance & accountability: Model registry with versioning; signed releases; prompt/dataset/job logging with privacy-preserving redaction; explain- ability notes for high-risk features; human-oversight checkpoints as required by the EU AI Act. 45 AI Sandbox for Industry–Academia CollaborationGovernance and Policy Framework • (4) Interoperability & access control: Identity federation (SAML/OIDC), SCIM provisioning, standard APIs; organisation boundaries ensure partners do not re- quire broad access to each other’s systems. • (5) Compliance & legal risk: DPIA triggers evaluated during intake; DPAs/DSAs linked to datasets; audit-ready evidence (approvals, lineage, logs); lawful-basis and residency enforced by policy as code. • Cross-cutting: cost control: Per-project budgets and alerts; fair-share scheduling; idle shutdown; reserved vs. on-demand GPU policies. • Cross-cutting: data hygiene: Intake QA checks (schema, PII scanners); required metadata completeness; prohibited-content filters for training corpora; dataset quality metrics tracked in the catalogue. Operational Metrics and SLAs To keep the baseline measurable, we propose the following initial targets (refined with the Steering Group during pilot): • Security events: Mean time to detect (MTTD) S1 ≤ 4 h; mean time to contain (MTTC) S1≤ 24 h; incident report and lessons learned published within 10 business days. • Patching: Critical CVEs remediated within 7 days; high within 30 days. • Backups: RPO≤ 24 h; RTO≤ 8 h for core control plane; quarterly restore test. • Access governance: Quarterly access recertification; approval SLAs per Table 4.2; automated expiry for time-bound grants. • Logging retention: Security logs≥ 12 months (immutable); dataset/model lineage retained for the life of the project plus contractual/archive period. Compliance Mapping (overview) • GDPR: Security of processing (Art. 32), breach notification (Arts. 33–34), records of processing (Art. 30), and privacy by design/default (Art. 25) operationalised through IAM, isolation, encryption, logging, and incident playbooks. Controllers remain responsible for legal bases; the Operator provides processor-level TOMs and evidence. • EU AI Act (high-level): For higher-risk features, the sandbox enables risk man- agement and logging, technical documentation, transparency to users, human oversight checkpoints, and robustness/cybersecurity controls; conformity activi- ties remain the responsibility of the provider/user of the AI system. • Finnish practice for sensitive data: Where applicable, Findata/THL/FSD permit conditions are enforced via isolated workspaces, export review, and documented disclosure control. 46 AI Sandbox for Industry–Academia CollaborationGovernance and Policy Framework Table 4.3: Summary of Security Baseline and Incident Response Measures DomainKey MeasuresRegulatory / Standard Alignment Identity and Access Man- agement Multi-factor authentication (MFA) for admins, dataset uploaders, and approvers; strong pass- word and session policies; role-based access with least privilege GDPR Art. 32 (security of process- ing), ISO/IEC 27001 (A.9), NIST IAM controls Data SecurityEncryption at rest and in transit (AES-256, TLS 1.2+); network isolation for sensitive projects; se- crets management; audit-ready logging of data ac- cess GDPR Art. 25 (data protection by design), EU AI Act (data han- dling), ISO/IEC 27018 (cloud PII protection) Assurance and Monitor- ing Monthly automated vulnerability scans; annual penetration testing; continuous monitoring dash- boards; Software Bill of Materials (SBOM) for de- pendencies ISO/IEC 27001 (A.12, A.18), EU NIS2 Directive (cybersecurity baseline), ENISA cloud security guidelines Incident ResponseStructured lifecycle: triage → containment → eradication → recovery → post-mortem review; breach notifications within 72h; communication with stakeholders GDPR Art. 33 (breach notifica- tion), ISO/IEC 27035 (incident re- sponse), NIS2 (reporting duties) 4.1.8 Change Control, Versioning, and Exit Strategy The governance framework of the AI Sandbox must evolve in step with regulatory, technological, and organisational changes. To maintain continuity, transparency, and legal certainty, we propose the following mechanisms: • Policy review and versioning: Governance documents are reviewed at least an- nually, or earlier if triggered by regulatory changes, newly identified risks, or stakeholder requests. Semantic versioning (major/minor/patch) is applied, and all historic versions are archived for reference. • Change management: Formal change proposals are submitted with defined con- sultation windows for stakeholder input. The Steering Group approves material amendments following documented deliberation. Minor technical or editorial updates may be delegated to the Sandbox Operator, with notification to all stake- holders. • Exit and off-boarding: Participants who leave the sandbox receive support for secure data export, model handover, and transfer of relevant metadata. Accounts are closed in a controlled process, including deletion or cryptographic erasure of remaining data, with a verifiable certificate of destruction issued. 4.1.9 Implementation Link: Policy↔ Technology To be effective, governance rules must be enforceable within the technical fabric of the sandbox. We therefore propose a continuous mapping of policy requirements to concrete platform controls: • Access control: Role-based access control (RBAC) and multi-level approval work- flows enforce the principles defined in the governance model. • Data governance: Storage and processing are classified by data type (public, internal, sensitive), with residency and retention controls enforced automatically. 47 AI Sandbox for Industry–Academia CollaborationGovernance and Policy Framework • Evidence capture: Experiment tracking and system logs provide immutable records of approvals, dataset use, model training, and releases, supporting au- dits and regulatory compliance. • Compliance dashboards: Real-time dashboards summarise quotas, approvals, data flows, and compliance indicators, allowing administrators and auditors to monitor adherence to both sandbox policies and EU/Finnish regulatory obliga- tions. This linkage is maintained as a living appendix to the governance framework, updated alongside each platform release, ensuring that changes in regulation or policy translate directly into enforceable and auditable technical measures. 4.2 Glossary of Abbreviations Table 4.4: Glossary of Abbreviations and Definitions Used in the Governance Framework AbbreviationDefinition / Reference GDPRGeneral Data Protection Regulation (Regulation (EU) 2016/679). Core EU law on data protec- tion and privacy. EU AI ActArtificial Intelligence Act, Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence (risk-based framework with phased application). DPAData Processing Agreement, required by GDPR Art. 28 between data controllers and proces- sors, defining responsibilities and safeguards. DSAData Sharing Agreement, contractual mechanism to allow inter-organisational data access while defining lawful basis, security measures, and responsibilities. DPIAData Protection Impact Assessment, a mandatory risk assessment for high-risk data processing under GDPR Art. 35. SBOMSoftware Bill of Materials, a formal record of components, dependencies, and licences in a software product (ISO/IEC 5962:2021). IAMIdentity and Access Management: security processes and tools for role-based and attribute- based access, including authentication and authorisation. MFAMulti-Factor Authentication: security method requiring multiple credentials for access (e.g., password + hardware token). RPORecovery Point Objective: maximum tolerable period in which data might be lost due to an incident. RTORecovery Time Objective: target time to restore systems after a disruption. NIS2 DirectiveDirective (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (successor to the NIS Directive). ENISAEuropean Union Agency for Cybersecurity. Provides guidelines, incident response recom- mendations, and security baselines. ISO/IEC 27001International standard for information security management systems (ISMS). Basis for many controls cited in the framework. ISO/IEC 27701Privacy extension to ISO/IEC 27001, providing requirements for data privacy management. ISO/IEC 23894:2023International standard for AI risk management, aligned with risk-management obligations discussed in the EU AI Act context. NIST SP 800-61US National Institute of Standards and Technology Special Publication 800-61: Computer Security Incident Handling Guide. Provides phases for incident response. 48 AI Sandbox MVP 5.1 Overview The current Minimum Viable Product (MVP) of the AI Sandbox demonstrates how se- cure, compliant, and collaborative AI experimentation can be achieved within a unified technical and governance framework. The system is deployed on the CSC Rahti cloud platform 1 and its source code, configuration scripts, and operational documentation are maintained in the GPT Lab repository 2 . A complementary Wiki provides guidance for deployment on institutional or private infrastructures, supporting reproducibility across research and industrial partners. The MVP realises the core functions of the Sandbox: identity and access management, project governance, AI-service orchestration, hardware resource control, and collabora- tion hubs for universities and companies. The following sections illustrate the working prototype through representative screenshots and describe how the architecture can scale toward production. 5.2 System Architecture and Key Components The deployed environment follows a modular microservices architecture designed for extensibility and security. Each service runs as an independent container within a Kubernetes-based platform on CSC Rahti, connected through secured REST APIs. The main components include: • Access Gateway and Landing Interface: Entry point with authentication and access controls. In the current prototype, access is handled through the platform’s account workflows and token-based sessions; institutional federation (for example via OpenID Connect) is treated as an integration path for production deployments. • Academic and Organisational Hubs: Controlled workspaces for universities, com- panies, and joint projects with fine-grained access policies. • Dashboard and User Management: Central administration for users, roles, and permissions across tenants. • Hardware and Resource Management: Interfaces for GPU/CPU allocation, quota monitoring, and usage analytics. • AI Services and Model Evaluation: Execution and benchmarking environment for LLMs and other AI models. • Data and Compliance Layer: Enforcement of encryption, residency, and lawful- basis policies defined in the governance framework. 1 https://gptlab-frontend-gptlab-sandbox.2.rahtiapp.fi/collaborations/discovery 2 https://github.com/GPT-Laboratory/GPT-Lab-Sandbox 49 AI Sandbox for Industry–Academia CollaborationAI Sandbox MVP 5.3 User Interface Demonstration The following figures illustrate selected interfaces of the deployed Sandbox MVP. They reflect the role-based experience and show functional integration of security, usability, and collaboration. 5.3.1 Landing Page and Access Gateway The landing interface provides authenticated access to the Sandbox and introduces available services for academic and industrial participants. Figure 5.1: Landing page and secure access gateway of the Sandbox MVP. 5.3.2 Academic and Research Hub The Academic Hub consolidates institutional projects, datasets, and AI service connec- tions, providing a clear overview of academic participation. 50 AI Sandbox for Industry–Academia CollaborationAI Sandbox MVP Figure 5.2: Academic Hub view showing institutional projects and datasets 5.3.3 Company Hub and Collaboration Environment The Sandbox supports structured onboarding of companies and industry partners. Each organisation manages its members and projects independently, with isolation and secure data-sharing zones. 51 AI Sandbox for Industry–Academia CollaborationAI Sandbox MVP Figure 5.3: Company hub displaying industrial participants and collaboration interfaces. 5.3.4 System Dashboard and User Management The unified dashboard provides administrators with visibility into platform usage and user activities. It integrates account management, approvals, and security role definitions for academic and corporate users. 52 AI Sandbox for Industry–Academia CollaborationAI Sandbox MVP Figure 5.4: System dashboard providing visibility across organisational and project layers. 5.3.5 Hardware and Resource Management Administrators and project leads allocate computational resources through the hardware- management interface, which supports quotas, resource pools, and real-time utilisation monitoring. 53 AI Sandbox for Industry–Academia CollaborationAI Sandbox MVP Figure 5.5: Hardware-management interface for GPU/CPU allocation and monitoring. 54 AI Sandbox for Industry–Academia CollaborationAI Sandbox MVP 5.3.6 AI Services and Model Evaluation The AI Services module provides tools for deploying, testing, and benchmarking lan- guage models under the Sandbox’s compliance and governance framework. Figure 5.6: AI Services module listing available AI models and workflows. 5.3.7 LLM Comparison and Benchmarking (One example) The Sandbox includes a comparison service that allows users to evaluate multiple LLMs, including open and proprietary options, on shared tasks. This module supports evidence-based model selection by comparing response accuracy, latency, and cost- efficiency. 55 AI Sandbox for Industry–Academia CollaborationAI Sandbox MVP Figure 5.7: Model benchmarking and comparative evaluation of multiple LLMs within the Sandbox. 5.4 Repository and Documentation Access The implementation is available in the GPT Lab GitHub repository, which serves as the source for code, container definitions, and automation scripts: https://github.com/GPT-Laboratory/SW4E-s-Sandbox 56 AI Sandbox for Industry–Academia CollaborationAI Sandbox MVP Comprehensive documentation, including deployment instructions for CSC Rahti, OpenShift, and on-premises environments, is provided in the project Wiki. The docu- mentation covers: • Step-by-step deployment and configuration • Integration with institutional identity providers (where applicable) • Role and permission mapping consistent with the governance model • Monitoring, auditing, and security best practices 5.5 Summary The deployed MVP demonstrates the technical feasibility of the AI Sandbox and the practicality of its governance-driven design. Its modular, containerised architecture supports extension to additional AI services, while embedded security and audit mech- anisms support GDPR compliance and EU AI Act readiness. Through its open-source release and documentation in the GPT Lab repository, the Sandbox provides a reusable foundation for organisations seeking to develop, evaluate, and govern AI systems re- sponsibly within shared research and innovation infrastructures. 57 Frequently Asked Questions As the Sandbox moves toward real-world deployment, a number of recurring questions arise from companies, data controllers, and research partners regarding compliance, intellectual property, data protection, and accountability. This chapter summarises the most frequent concerns and provides concise answers that translate the governance and technical safeguards into practical, real-world assurances. Q1: How will sensitive business data be protected once uploaded into the sandbox? All uploaded data is protected under GDPR Article 32 (Security of Processing) and the Finnish Data Protection Act (1050/2018). Data is encrypted in transit (TLS 1.2+) and at rest (AES-256), stored in EU/EEA data centres, and isolated per tenant. We apply data-protection-by-design (GDPR Art. 25) and align our security controls with ISO/IEC 27001-aligned practices and zero-trust principles to ensure end-to-end protection. Q2: Will encryption and access controls be strong enough to prevent leaks between collaborators? Yes. The Sandbox enforces strong role-based access control (RBAC), multi-factor authentication (MFA), and strict tenant isolation under GDPR Art. 32(1) and com- mon NIS2-aligned cybersecurity practices. Encryption key management can sup- port customer-managed keys where required by the deployment environment and operating model, ensuring that only authorised parties can decrypt protected data. Q3: Where will the data be physically stored, and how will GDPR or sector-specific compliance be ensured? Data residency is enforced within EU/EEA regions (primarily Finland) to comply with GDPR Chapter V on international transfers. No personal or regulated data will be transferred outside the EEA without a valid transfer mechanism such as an adequacy decision or Standard Contractual Clauses (SCCs). Sector-specific rules (e.g., healthcare, finance) are implemented through isolated workspaces, stricter access controls, and documented Data Protection Impact Assessments (DPIAs) under GDPR Art. 35 where required. Q4: Who will own the outputs generated by the LLM when multiple organisations contribute data or prompts? Each participant retains ownership of its own inputs (data, prompts, models). Outputs and co-created artefacts follow the project or collaboration agreement, in line with the Finnish Copyright Act (404/1961) and the EU Trade Secrets Direc- tive 2016/943. Unless otherwise agreed in writing, jointly created results will be jointly owned. Q5: How will proprietary know-how be protected during collaboration? Proprietary information is safeguarded through tenant and project isolation, confi- 58 AI Sandbox for Industry–Academia CollaborationFrequently Asked Questions dentiality terms in collaboration agreements, and data-protection-by-design (GDPR Art. 25). Each project operates in an isolated workspace, and cross-project data mixing is not permitted unless explicitly approved and contractually defined. Logging and provenance tracking support controlled use and help prevent accidental disclosure of trade secrets. Q6: How will derivative models or works be handled? Derivative models and works are governed by explicit licence terms defined in the relevant project or collaboration agreement. The Sandbox operator does not claim ownership of participant outputs and does not reuse them outside the agreed scope. Practices are aligned with Finnish intellectual property law and applicable EU copyright principles. Q7: If the LLM produces incorrect, biased, or harmful outputs, who will be respon- sible? Responsibility is defined through the applicable controller/processor roles under GDPR and through project-specific contracts. The Sandbox maintains traceability through version control, logging, and audit records, supporting accountability and the documentation and oversight expectations associated with EU AI Act risk management, transparency, and human oversight. Q8: Will companies be able to trace which prompts, datasets, or users produced a specific output? Yes. Model runs can be logged with user identity, timestamp, dataset reference (for example hashes or identifiers), and model/version metadata. These records can be exported for independent audit or regulator review, supporting traceability and accountability. Q9: How will you ensure explainability and trust in model outputs? The Sandbox supports documentation and interpretability measures, including dashboards where appropriate. Each output can be linked to the model version, dataset reference, and execution context. Human-in-the-loop review checkpoints can be applied for sensitive use cases to strengthen transparency and align with AI Act expectations on user information and human oversight. Q10: How will secure access be managed when companies use different cloud or IT systems? The Sandbox can support federated identity management via OpenID Connect or SAML 2.0, combined with MFA. Access rights are managed through role- based and attribute-based controls, consistent with GDPR Art. 32(1)(b) and widely adopted ENISA-aligned best practices for cross-organisational security. Q11: Will collaborators be able to access each other’s internal systems accidentally? No. The platform is designed to enforce project and tenant boundaries through network segmentation, strict access controls, and API-layer authorisation. By design, data and services do not flow between tenants or organisations unless explicitly configured and approved. Q12: How will collaboration remain smooth without over-exposing internal assets? The Sandbox provides controlled collaboration mechanisms that allow partners to share datasets or results with fine-grained permissions. Core systems and 59 AI Sandbox for Industry–Academia CollaborationFrequently Asked Questions private project assets remain isolated, supporting the purpose-limitation principle (GDPR Art. 5(1)(b)). Q13: How will you ensure overall compliance with GDPR and the EU AI Act? Compliance is embedded by design. We conduct Data Protection Impact As- sessments (DPIAs) for high-risk processing where required (GDPR Art. 35) and maintain Records of Processing Activities (Art. 30). Compliance reviews and au- dits are carried out under the agreed governance model, supporting continuous alignment with GDPR obligations and EU AI Act readiness. Q14: Who will be liable if the system is misused or regulatory breaches occur? Liability is defined through controller/processor arrangements and project-specific contracts. Each participant remains responsible for its own data and actions, while the operator remains responsible for agreed operational and security mea- sures within its role. Audit records and incident response procedures support accountability and, where applicable, redress. Q15: How will export control, sector-specific, or antitrust regulations be addressed? Projects can be screened against relevant export-control rules (including the EU Dual-Use Regulation 2021/821) and sectoral frameworks where applicable. Col- laborations are structured to avoid inappropriate information sharing that could raise competition-law concerns (TFEU Articles 101–102). Sensitive datasets are processed within controlled EU/EEA environments, with logging and access con- trols applied throughout. Q16: Will audit trails and contracts be maintained for legal defensibility? Yes. Audit trails, access records, and relevant project documentation are retained according to the retention policy defined in the governance framework and appli- cable contractual or regulatory requirements. Service Level Agreements (SLAs) and Data Processing Agreements (DPAs), where used, include audit and account- ability clauses to support defensibility. Q17: How will cloud cost and resource usage be controlled? The Sandbox supports transparent usage monitoring with resource caps, quotas, and dashboards. These mechanisms help prevent cost overruns and support sus- tainable operations, including energy-aware practices where they are measurable and applicable. Q18: How will data quality and trust in partners’ datasets be ensured? A Data Quality Policy is applied in line with the data governance requirements relevant to the use case, including EU AI Act expectations for data governance for high-risk systems. Datasets undergo validation for accuracy, completeness, and lawful provenance before being used for training or analysis, and the outcomes are recorded in dataset metadata where applicable. The questions and answers presented above reflect the Sandbox’s guiding principles of openness, neutrality, accountability, and trust. Together they demonstrate how governance, security, and compliance are implemented not merely as policies but as integral technical and organisational features of the platform. The following chapter summarises how these principles converge into a sustainable, secure, and transparent model for responsible AI collaboration. 60 Conclusions Building upon this foundation, the Sandbox was developed through a structured process that combined stakeholder engagement, architectural design, and iterative validation. Each phase, from requirements analysis to technical implementation and governance formulation, was aligned with the principles of security, transparency, and collaboration. The following development milestones demonstrate how these principles were translated into a functioning, compliant, and extensible platform. The Sandbox requirements were identified, analysed, and prioritised through consulta- tions with key stakeholders to ensure that data sensitivity, localisation, and regulatory compliance needs were addressed from the outset. This collaborative process brought together technical experts, researchers, and institutional representatives to define func- tional and non-functional requirements reflecting both operational and ethical consid- erations. As a result, the Sandbox evolved as a coherent response to the diverse needs of academia, industry, and the public sector, balancing flexibility with accountability and ensuring that user expectations are met within a secure and compliant environment. The technical architecture of the Sandbox was developed as a modular, container-based system designed for scalability, interoperability, and controlled experimentation. It fol- lows a microservices model with defined layers for orchestration, data management, model services, and security. The technology stack integrates Docker for containerisa- tion, Kubernetes for orchestration, and RESTful APIs for service communication. Core components are implemented using Node.js/Express and Next.js for the prototype control plane and user interface, with SQLite used for prototype persistence and a migration path to PostgreSQL for production-scale deployments. Security-by-design principles are applied throughout, employing encryption, role-based access control, audit logging, and network isolation to support data integrity and system resilience. This combination of technologies and practices enables the platform to meet techni- cal performance requirements while supporting the data protection and cybersecurity expectations associated with European regulation. The governance and policy framework establishes how the platform operates as a trusted, transparent, and accountable environment. It defines operational roles, access permissions, and data-handling procedures that align with the GDPR, the EU AI Act, and relevant international standards. Governance mechanisms clarify responsibili- ties across participants, ensuring that activities within the Sandbox remain traceable, auditable, and compliant. This approach promotes fairness and transparency while embedding trust in the operating model. By integrating legal and ethical oversight directly into the system design, the Sandbox treats compliance as a continuous and verifiable process rather than a one-time obligation. The Minimum Viable Product (MVP) demonstrates the technical and organisational feasibility of secure and collaborative AI experimentation. It provides controlled ac- 61 AI Sandbox for Industry–Academia CollaborationConclusions cess to resources, enables cooperative workflows among different institutions, and supports the orchestration of AI services, models, and data pipelines within a defined governance structure. The MVP validates the overall system design and confirms that complex experimentation can occur in an environment that supports privacy, account- ability, and reproducibility. It serves as both a proof of concept and a foundation for future expansion, establishing the Sandbox as a functional environment for responsible AI research and innovation. Overall, the Sandbox demonstrates that responsible and innovative AI experimentation can coexist within a single infrastructure when guided by transparent governance, a secure technological foundation, and sustained stakeholder collaboration. Its architec- ture and operating model provide a stable base for future scaling, connecting research, policy, and practice through a shared framework of trust, transparency, and technically grounded implementation. 62 Bibliography [1] Eric Breck, Shanqing Cai, Eric Nielsen, Michael Salib, and D. Scul- ley.The ml test score: A rubric for ml production readiness and technical debt reduction.In 2017 IEEE International Conference on Big Data (Big Data), 2017. URL: https://research.google/pubs/ whats-your-ml-test-score-a-rubric-for-ml-production-systems/. [2] Henry Chesbrough. Open Innovation: The New Imperative for Creating and Profiting from Technology. Harvard Business School Press, 2003. [3] Paul Cichonski, Tom Millar, Tim Grance, and Karen Scarfone. Computer secu- rity incident handling guide (sp 800-61, rev. 2). Technical report, National Insti- tute of Standards and Technology (NIST), 2012. URL: https://csrc.nist.gov/ publications/detail/sp/800-61/rev-2/final. [4] Creative Commons. Creative commons C0 1.0 Universal public domain dedica- tion. https://creativecommons.org/publicdomain/zero/1.0/, 2009. Accessed 11 October 2025. [5] Creative Commons. Creative commons attribution 4.0 international (C BY 4.0). https://creativecommons.org/licenses/by/4.0/legalcode, 2013. Accessed 11 October 2025. [6] CSC – IT Center for Science. ELIXIR Finland at CSC: Research infrastructure overview. https://csc.fi/researchinfrastructure/elixir/, 2024. [7] CSC – IT Center for Science. CSC—it center for science, finland. https://w. csc.fi/en, 2025. Accessed 11 October 2025. [8] CSC – IT Center for Science. ELIXIR Finland—life science data services. https: //w.csc.fi/en/elixir-finland, 2025. Accessed 11 October 2025. [9] Tim Dierks and Eric Rescorla. The transport layer security (TLS) protocol version 1.2. Technical Report RFC 5246, RFC Editor, 2008. https://w.rfc-editor. org/rfc/rfc5246. doi:10.17487/RFC5246. [10] Digital and Population Data Services Agency. All finnish open data from one place—avoindata.fi. https://w.avoindata.fi/en, 2022. [11] Docker, Inc. Docker documentation: Multi-stage builds. https://docs.docker. com/build/building/multi-stage/, 2025. Accessed 11 October 2025. [12] ELIXIR Finland. Services, data archives, and access. https://w. elixir-finland.org/, 2025. [13] Henry Etzkowitz and Loet Leydesdorff. The dynamics of innovation: From na- tional systems and "mode 2" to a triple helix of university–industry–government 63 AI Sandbox for Industry–Academia CollaborationBibliography relations. Research Policy, 29(2):109–123, 2000. doi:10.1016/S0048-7333(99) 00055-4. [14] European Commission. Making the most of the EU’s innovative potential: An intellectual property action plan to support the EU’s recovery and resilience. Euro- pean Commission, COM(2020) 760 final, 2020. Accessed 11 October 2025. https: //eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52020DC0760. [15] European Commission. Horizon europe model grant agreement. European Commission, 2021. Accessed 11 October 2025. https://ec.europa.eu/info/ funding-tenders/opportunities/docs/2021-2027/common/guidance/aga_en. pdf. [16] European Commission. data.europa.eu: EU open data portal documentation and APIs. https://data.europa.eu/en/about/documentation, 2024. [17] European Data Protection Board. Guidelines on data protection impact assess- ment (dpia) and determining whether processing is "likely to result in a high risk" (wp248 rev.01), 2017. URL: https://ec.europa.eu/newsroom/article29/ items/611236/en. [18] European Parliament and Council of the European Union. Directive (EU) 2016/943 on the protection of undisclosed know-how and business information (Trade Secrets). Official Journal of the European Union, L 157, 2016. Accessed 11 October 2025. https://eur-lex.europa.eu/eli/dir/2016/943/oj. [19] European Parliament and Council of the European Union. Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data (General Data Protection Regulation). Official Journal of the Euro- pean Union, L 119, 2016. Accessed 11 October 2025. https://eur-lex.europa. eu/eli/reg/2016/679/oj. [20] European Parliament and Council of the European Union. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the union (NIS 2 Directive). https://data.europa.eu/eli/dir/2022/2555/oj, 2022. [21] European Parliament and Council of the European Union. Regulation (EU) 2024/1689 of the european parliament and of the council of 13 june 2024 lay- ing down harmonised rules on artificial intelligence (Artificial Intelligence Act). https://data.europa.eu/eli/reg/2024/1689/oj, 2024. [22] European Union Agency for Cybersecurity. Artificial intelligence cyber- security challenges: Threat landscape for ai. Report, European Union Agency for Cybersecurity, 2020. https://w.enisa.europa.eu/publications/ artificial-intelligence-cybersecurity-challenges. [23] European Union Agency for Cybersecurity. Securing machine learning algorithms. Report, European Union Agency for Cybersecurity, 2021. https://w.enisa. europa.eu/publications/securing-machine-learning-algorithms. 64 AI Sandbox for Industry–Academia CollaborationBibliography [24] Roy T. Fielding, Mark Nottingham, and Julian Reschke. HTTP caching. Tech- nical Report RFC 9111, RFC Editor, 2022. https://w.rfc-editor.org/info/ rfc9111. doi:10.17487/RFC9111. [25] Roy T. Fielding, Mark Nottingham, and Julian Reschke. HTTP semantics. Tech- nical Report RFC 9110, RFC Editor, 2022. https://w.rfc-editor.org/info/ rfc9110. doi:10.17487/RFC9110. [26] Findata. Social and health data permit authority. https://findata.fi/en/, 2025. [27] Finland. Data protection act 1050/2018. https://finlex.fi/en/legislation/ translations/2018/eng/1050, 2018. [28] Finnish Institute for Health and Welfare. THL Sotkanet: Site guide and API endpoints. https://sotkanet.fi/sotkanet/en/ohje/74, 2023. [29] Finnish Social Science Data Archive. Aila data service and guidelines. https: //w.fsd.tuni.fi/en/, 2025. [30] Martin Fowler. Microservice prerequisites, 2014. Accessed 2025-10-11. URL: https://martinfowler.com/bliki/MicroservicePrerequisites.html. [31] Martin Fowler. Microservice premium, 2015. Accessed 2025-10-11. URL: https: //martinfowler.com/bliki/MicroservicePremium.html. [32] Martin Fowler and James Lewis. Microservices, 2014. Accessed 2025-10-11. URL: https://martinfowler.com/articles/microservices.html. [33] Vincent C. Hu, David Ferraiolo, Rick Kuhn, Adam Schnitzer, Kenneth Sandlin, and Ramaswamy Chandramouli. Guide to attribute based access control (abac) definition and considerations. Technical Report SP 800-162, NIST, 2014. Accessed 2025-10-11. URL: https://csrc.nist.gov/pubs/sp/800/162/upd2/final. [34] Hugging Face. Hugging face: Access the inference API. https://huggingface. co/docs/huggingface_hub/v0.14.1/en/guides/inference, 2024. Accessed 11 October 2025. [35] Hugging Face. Hugging face: Inference providers and HF inference. https:// huggingface.co/docs/inference-providers/index, 2025. Accessed 11 October 2025. [36] International Organization for Standardization. ISO/IEC/IEEE 29148:2018 sys- tems and software engineering—life cycle processes—requirements engineering. International Standard, 2018. https://w.iso.org/standard/72089.html. [37] International Organization for Standardization. ISO/IEC 27001:2022 informa- tion security, cybersecurity and privacy protection—information security manage- ment systems—requirements. International Standard, 2022. Accessed 11 October 2025. https://w.iso.org/standard/82875.html. 65 AI Sandbox for Industry–Academia CollaborationBibliography [38] International Organization for Standardization. ISO/IEC 23894:2023 information technology—artificial intelligence—guidance on risk management. International Standard, 2023. https://w.iso.org/standard/77304.html. [39] International Organization for Standardization. ISO/IEC 42001:2023 Information technology—Artificial intelligence—Management system. International Standard, 2023. https://w.iso.org/standard/81230.html. [40] Michael Jones. JSON web algorithms (JWA). Technical Report RFC 7518, RFC Edi- tor, 2015. https://w.rfc-editor.org/rfc/rfc7518. doi:10.17487/RFC7518. [41] Michael Jones, John Bradley, and Nat Sakimura. JSON web signature (JWS). Technical Report RFC 7515, RFC Editor, 2015. https://w.rfc-editor.org/ rfc/rfc7515. doi:10.17487/RFC7515. [42] Michael Jones, John Bradley, and Nat Sakimura. RFC 7519: JSON Web Token (JWT). https://w.rfc-editor.org/rfc/rfc7519, 2015. [43] Michael Jones and Joe Hildebrand. JSON web encryption (JWE). Technical Report RFC 7516, RFC Editor, 2015. https://w.rfc-editor.org/rfc/rfc7516. doi: 10.17487/RFC7516. [44] Kubernetes Authors. Kubernetes concepts overview. https://kubernetes.io/ docs/concepts/overview/, 2024. [45] Kubernetes Authors. Kubernetes multi-tenancy: Security concepts. https:// kubernetes.io/docs/concepts/security/multi-tenancy/, 2025. [46] Ninghui Li, Tiancheng Li, and Suresh Venkatasubramanian. t-closeness: Privacy beyond k-anonymity and l-diversity. In Proceedings of the 23rd IEEE International Conference on Data Engineering (ICDE 2007), pages 106–115, 2007. doi:10.1109/ ICDE.2007.367856. [47] Ashwin Machanavajjhala, Daniel Kifer, Johannes Gehrke, and Muthuramakrish- nan Venkitasubramaniam. ℓ-diversity: Privacy beyond 푘-anonymity. ACM Trans- actions on Knowledge Discovery from Data, 1(1):3, 2007. URL: https://scholars. duke.edu/publication/808886, doi:10.1145/1217299.1217302. [48] Meta Platforms, Inc. React documentation: Quick start. https://react.dev/ learn, 2025. Accessed 11 October 2025. [49] National Institute of Standards and Technology. FIPS 197: Advanced encryption standard (AES). Technical Report FIPS PUB 197, National Institute of Standards and Technology, 2001. Updated 9 May 2023; no technical changes. https://csrc. nist.gov/pubs/fips/197/final. [50] National Institute of Standards and Technology. Security and privacy controls for information systems and organizations (SP 800-53 Rev. 5). Technical Report NIST Special Publication 800-53 Revision 5, National Institute of Standards and Technology, 2020. https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final. 66 AI Sandbox for Industry–Academia CollaborationBibliography [51] National Institute of Standards and Technology. Artificial intelligence risk manage- ment framework (AI RMF 1.0). Technical Report NIST AI 100-1, National Institute of Standards and Technology, 2023. https://nvlpubs.nist.gov/nistpubs/ai/ NIST.AI.100-1.pdf. [52] National Institute of Standards and Technology. NIST SP 800-63B-4: Digital iden- tity guidelines—authentication and authenticator management. Technical Report NIST Special Publication 800-63B-4, National Institute of Standards and Technol- ogy, 2025. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST. SP.800-63b-4.pdf. [53] OASIS Consortium. Assertions and protocols for the oasis security assertion markup language (saml v2.0), 2005. URL: https://docs.oasis-open.org/ security/saml/v2.0/saml-core-2.0-os.pdf. [54] OpenAI. Openai platform: API reference. https://platform.openai.com/docs/ api-reference, 2025. Accessed 11 October 2025. [55] OpenID Foundation. OpenID Connect Core 1.0. https://openid.net/specs/ openid-connect-core-1_0.html, 2014. Accessed 11 October 2025. [56] OpenJS Foundation. Express 4.x API reference. https://express.nodejs.cn/ en/4x/api.html, 2025. Accessed 11 October 2025. [57] OpenTelemetry Authors. OpenTelemetry specifications. https://opentelemetry. io/docs/specs/, 2024. Accessed 11 October 2025. [58] OpenTelemetry Authors. OpenTelemetry Protocol (OTLP) specification. https: //opentelemetry.io/docs/specs/otlp/, 2025. Accessed 11 October 2025. [59] Organisation for Economic Co-operation and Development. Recommendation of the council on oecd legal instruments oecd guidelines for managing conflict of interest in the public service, 2003. URL: https://legalinstruments.oecd.org/ public/doc/130/130.en.pdf. [60] Organisation for Economic Co-operation and Development. OECD recommen- dation of the council on artificial intelligence (OECD/LEGAL/0449). https: //legalinstruments.oecd.org/en/instruments/OECD-LEGAL-0449, 2019. [61] Project-Management.com.Understanding the responsibility assign- ment matrix (RACI matrix). https://project-management.com/ understanding-responsibility-assignment-matrix-raci-matrix/,2024. Accessed 11 October 2025. [62] Prometheus Authors. Prometheus documentation: Overview. https:// prometheus.io/docs/introduction/overview/, 2025. Accessed 11 October 2025. [63] Eric Rescorla. The transport layer security (TLS) protocol version 1.3. Technical Report RFC 8446, RFC Editor, 2018. https://w.rfc-editor.org/rfc/rfc8446. doi:10.17487/RFC8446. 67 AI Sandbox for Industry–Academia CollaborationBibliography [64] Ravi Sandhu, Edward Coyne, Hal Feinstein, and Charles Youman. Role-based access control models. IEEE Computer, 29(2):38–47, 1996. URL: https: //csrc.nist.gov/CSRC/media/Projects/Role-Based-Access-Control/ documents/sandhu96.pdf. [65] D. Sculley, G. Holt, D. Golovin, E. Davydov, T. Phillips, D. Ebner, V. Chaud- hary, M. Young, J. Crespo, and D. Dennison. Hidden technical debt in ma- chine learning systems. In Advances in Neural Information Processing Systems (NeurIPS), 2015. URL: https://proceedings.neurips.c/paper/2015/file/ 86df7dcfd896fcaf2674f757a2463eba-Paper.pdf. [66] Statistics Finland. Pxweb open data API: Help and documentation. https:// stat.fi/media/uploads/org_en/avoindata/px-web_api-help.pdf, 2024. [67] Latanya Sweeney. 푘-anonymity: A model for protecting privacy. Interna- tional Journal of Uncertainty, Fuzziness and Knowledge-Based Systems, 10(5):557–570, 2002. URL: https://worldscientific.com/doi/10.1142/S0218488502001648, doi:10.1142/S0218488502001648. [68] Vercel. Next.js documentation: App router—routing. https://nextjs.org/ docs/13/app/building-your-application/routing, 2025. Accessed 11 October 2025. [69] Matei Zaharia, Andrew Chen, Aaron Davidson, Ali Ghodsi, Sid Hong, Andy Kon- winski, S. Murching, T. Nykodym, P. Ogilvie, M. Parkhe, et al. Accelerating the machine learning lifecycle with mlflow. Bulletin of the IEEE Computer Society Tech- nical Committee on Data Engineering, 2018. URL: https://people.eecs.berkeley. edu/~matei/papers/2018/ieee_mlflow.pdf. 68