Privacy-by-Design in AI-Assisted Systems for Caregivers of Children with Autism: A Secure Multi-Agent Architecture

Abstract

Caregivers of children with Autism Spectrum Disorder (ASD) frequently experience chronic psychological stress, thereby necessitating accessible support. Although artificial intelligence (AI)-based assisted technologies have the potential to reduce caregiver workload, most existing solutions lack robust privacy control and clinical interoperability, which significantly limits their adoption in regulated healthcare environments. To address these challenges, this paper proposes a Privacy-by-Design (PbD) multi-agent architecture that enables consent-aware, auditable, and privacy-preserving AI-assisted support for caregivers of children with ASD. The effectiveness of the proposed architecture was evaluated using two datasets: one focusing on clinically grounded autism-related knowledge and another reflecting naturalistic caregiver observation language. System performance was assessed using a Retrieval-Augmented Generation Assessment (RAGAs)-based framework with a Large Language Model (LLM)-as-a-Judge approach implemented via a locally deployed Llama 3 8B model. The system achieved answer relevancy scores of 0.767 for the clinical dataset and 0.750 for the observational dataset, with corresponding Recall@K values of 0.400 and 0.742, respectively. Context precision ranged from 0.599 to 0.631, and no harmful content was detected. Overall, the proposed architecture demonstrates secure caregiver–specialist collaboration through consent-aware routing, anonymised data storage, and controlled data reconstruction, providing a regulation-aligned design option for privacy-preserving AI integration in assisted care platforms.

1. Introduction

The significant increase in the prevalence of Autism Spectrum Disorder (ASD), currently estimated to affect approximately one in 100 children worldwide [1,2,3,4], has intensified attention not only on the needs of diagnosed individuals but also on the broader impact on their caregivers. Existing research indicates that caregivers of children with ASD frequently experience elevated levels of anxiety, fatigue, and emotional exhaustion due to the complex demands of caregiving [3,5,6]. Recent studies further report that nearly 75% of these caregivers experience moderate to severe anxiety on a daily basis [7]. These challenges are primarily associated with the need to manage behavioural disorders, communication impairments, and continuous monitoring, often in the context of insufficient external support. Over time, prolonged exposure to such stressors can significantly diminish caregivers’ quality of life and reduce the overall effectiveness of the care provided [2,8].

Access to specialised therapeutic services often poses additional challenges, particularly for families residing in rural or peri-urban areas located far from treatment centres, where geographical barriers frequently lead to prolonged disruptions in face-to-face interventions [9]. Consequently, there is a clear need for scientifically validated therapeutic interventions that can be implemented within the home environment, supported by modern digital technologies [10]. The objective of such initiatives is not to transfer full therapeutic responsibility to caregivers, but rather to strengthen collaboration between them and healthcare professionals through structured mechanisms for training, guidance, and continuous monitoring. Such an integrated, technology-enabled approach has the potential to optimise intervention processes and alleviate the psychological burden associated with caregiving, while simultaneously enhancing the long-term sustainability and efficiency of care delivery. Teletherapy platforms, mobile applications for parental coaching, behavioural monitoring systems, and socially assistive robots used in therapeutic contexts show considerable promise in complementing traditional interventions by enabling home-based support, parent training, and the acquisition of valuable data for the development of personalised treatment plans [11].

The widespread adoption of telemedicine in recent years has demonstrated the feasibility and effectiveness of remote therapeutic interventions, with meta-analyses indicating outcomes comparable to conventional in-person therapy, often at reduced costs [12]. A randomised controlled trial conducted by Lu et al. [13] found that, within only two weeks, integrating online support courses for parents of children with ASD significantly reduced caregiver stress levels and enhanced parental self-efficacy compared with control groups receiving traditional interventions alone. Remote support has also been associated with increased parental motivation, sustained engagement in training, and more active participation in the therapeutic processes [14]. These findings suggest that such tools can offer meaningful benefits, for instance, by enabling easier and faster access to specialist expertise regardless of geographic constraints and by enhancing collaboration between families and therapy teams through real-time virtual consultations. Moreover, teletherapy sessions can provide caregivers with restorative short breaks while maintaining continuity of therapeutic intervention for the child, thereby contributing to greater parental satisfaction and reduced burnout [14,15].

Building on these developments, assistive technologies have emerged as a broader approach for extending professional support into the home environment, mitigating caregiver fatigue, and enhancing the overall quality and continuity of home-based care delivery [16]. These systems encompass a wide range of digital solutions, including teletherapy platforms, mobile guidance applications, and sensor-based monitoring devices, that facilitate communication, therapy support, and behavioural management within daily caregiving routines. By enabling remote supervision and systematic data collection, assistive technologies bridge the gap between clinical and home environments, promoting continuity of care and expanding equitable access to therapeutic resources, regardless of geographical constraints.

Artificial Intelligence (AI)-based assistive technologies represent the next evolutionary stage in personalised and adaptive care delivery [17]. Intelligent systems employ Machine Learning algorithms, natural language processing, and computer vision techniques to analyse behavioural and contextual data, enabling automated feedback, adaptive interventions, and predictive monitoring. Through the structured acquisition and analysis of sensitive developmental data, AI-based systems can generate valuable insights that support clinical decision-making and enhance the design and optimisation of individualised therapeutic interventions. However, despite these notable advantages, privacy and data protection remain insufficiently addressed in contemporary assistive systems, representing a major barrier to their widespread and reliable deployment in real-world healthcare settings [18].

This paper aims to investigate the integration of Privacy-by-Design (PbD) principles within an AI-assisted system architecture designed to support caregivers of children with autism, ensuring data confidentiality and security from the outset while preserving system functionality and the associated benefits for caregivers. The successful deployment of such systems requires design practices that safeguard confidentiality, enforce robust privacy protections, and uphold ethical standards throughout the entire data lifecycle. Accordingly, the paper examines how PbD principles can be embedded within intelligent, context-aware assisted systems to support caregivers of children with autism. By building on the intersection of Privacy-by-Design and Multi-Agent System (MAS) paradigms, the research aims to bridge regulatory, architectural, and operational perspectives on trustworthy AI for sensitive healthcare application.

Accordingly, the paper addresses the following research questions:

RQ1: How can Privacy-by-Design principles be operationalised within a Multi-Agent System architecture for AI-assisted autism caregiver support?

RQ2: How can Privacy-by-Design-oriented multi-agent architecture contribute to sustainable and trustworthy AI ecosystems in digital health?

To address these questions, a Design Science Research (DSR) approach is adopted to (1) design, implement, and empirically evaluate a PbD-oriented MAS integrating Large Language Model (LLM) reasoning, consent management, and Data Loss Prevention (DLP) mechanisms; (2) assess system performance in terms of privacy preservation efficacy, inference latency, and information retrieval accuracy; and (3) analyse its implications for long-term governance, transparency, and sustainability in digital health AI infrastructures.

The main contributions of this paper are as follows:

-

We propose a PbD MAS architecture for AI-assisted caregiver support, integrating consent management, data loss prevention, Retrieval-Augmented Generation, and auditing mechanisms.

-

We implement a working Minimum Viable Product (MVP) supporting policy validation and end-to-end traceability and demonstrate the practical feasibility of the proposed architecture.

-

We operationalise the identified research gap through a set of explicit evaluation criteria (C1–C7) aligned with applicable regulatory and technical standards.

-

We conduct a comprehensive empirical evaluation based on 250 question–answer pairs across two distinct datasets, complemented by 30 access control validation test cases.

-

We define and apply a rigorous suite of formally specified metrics to assess retrieval performance, answer relevance, and access control effectiveness.

The remainder of the paper is structured as follows. Section 2 reviews existing approaches and theoretical foundations. Section 3 presents the system architecture and design principles. Section 4 and Section 5 report experimental evaluation and analyse the findings. Finally, Section 6 summarises the contributions and outlines directions for future research.

2. Related Works

AI-driven assisted technologies have substantially reshaped autism care by introducing digital health tools that enhance caregiver support and improve therapeutic outcomes. Teletherapy platforms and mobile-based parental coaching applications have been shown to reduce caregiver burnout and increase parental self-efficacy. Similarly, physiological signal-based stress detection systems achieve high accuracy when monitoring individuals with autism. Despite these advancements, most assisted solutions prioritise functional performance over data protection, leaving sensitive behavioural data vulnerable to unauthorised disclosure. Recent reviews highlight the absence of robust privacy safeguards and the insufficient integration of Privacy-by-Design principles in current implementations, a gap that undermines trust and limits the widespread adoption of these technologies [18,19].

Privacy-preserving frameworks and Federated Learning (FL) aim to enhance data protection in healthcare by leveraging distributed architectures. FL systems such as NVIDIA FLARE [20] and Substra [21] train models across decentralised nodes without exposing raw patient data. Both platforms use ledger-based traceability to ensure accountability. They represent state-of-the-art solutions for model training and Machine Learning Operations (MLOps). However, these systems exhibit notable limitations when applied for real-time caregiver support scenarios [22].

Moreover, existing frameworks (Appendix B) demonstrate limited interoperability with HL7 FHIR (Health Level Seven—Fast Healthcare Interoperability Resource) and lack support for granular consent management, both of which are essential for healthcare applications.

Retrieval-Augmented Generation (RAG) and safety in healthcare use cases depend on rigorous control over language model outputs. While LLMs provide conversational support, they also introduce risks related to hallucinations and factual inaccuracies. RAG mitigates these risks by grounding outputs in verified knowledge sources. Small Language Models (SLMs) enable local execution, thereby reducing the attack surface associated with data leakage and external exposure [23]. However, standard RAG pipelines rarely enforce strict version control for policies or automated data loss prevention mechanisms at the query stage. This limitation underscores the need for an integrated design that combines RAG with fail-closed consent rules and auditable controls aligned with General Data Protection Regulation (GDPR) [24] and the European Union Artificial Intelligence Act (EU AI Act) [25]. This study addresses this gap by introducing a Privacy-by-Design Multi-Agent System (PbD MAS) tailored to AI-assisted support for autism caregivers.

To make the identified gaps explicit and analytically well defined, we introduce a set of evaluation criteria (C1–C7) covering governance and auditability, consent orchestration, clinical interoperability, privacy-enhancing technologies, edge performance, local explainability, and federated lifecycle support. A criterion-based comparison of representative frameworks is provided in Appendix B. This analysis operationalises the gaps identified in this section and serves as a systematic foundation for the architectural requirements.

Theoretical Background

This section outlines the core theoretical conceptual frameworks underpinning the proposed architecture, namely Privacy-by-Design and Multi-Agent System architectures.

Privacy-by-Design framework. Dr Ann Cavoukian introduced the Privacy-by-Design framework as a proactive approach that embeds privacy considerations into the design of information systems, organisational practices, and digital infrastructures. Its primary objective is to prevent privacy risks before they occur by implementing seven foundational principles as an integrated model of protection [26]. In the current era of AI-driven assisted technology for caregivers of children with ASD, the application of PbD principles is essential for developing systems that are compliant with rigorous data protection regulation, including the GDPR [24], the Health Insurance Portability and Accountability Act (HIPAA) [27], the EU AI Act [25], the Children’s Online Privacy Protection Act (COPPA) [28], as well as applicable national legislation. Beyond regulatory compliance, PbD addresses critical requirements for enhanced data security and confidentiality maintenance in caregiver-oriented assisted systems.

The PbD framework requires a proactive stance, addressing risks before they materialise, through early assessments and built-in safeguards rather than reacting to breaches after system deployment. Privacy must operate as the default setting, ensuring that personal data are automatically protected without requiring user intervention. Protection is embedded directly into the architecture of systems and organisational practices, becoming a fundamental design element rather than an optional add-on. The framework rejects zero-sum trade-offs, demonstrating that privacy and full functionality can coexist in a positive-sum model. Robust security safeguards are applied across the entire data lifecycle, from collection and processing to storage and eventual deletion, ensuring that no stage remains unprotected. Transparency is essential, requiring systems to operate in ways that can be verified by users, regulators, and independent auditors. Finally, the PbD approach is user-centric, providing individuals with strong privacy defaults, clear notices, and accessible controls that enable individuals to manage their personal data effectively [26].

Multi-Agent Systems architecture. Multi-Agent Systems provide a conceptual and engineering framework for developing software systems composed of multiple interacting autonomous entities—referred to as agents—that cooperate, coordinate, or compete to achieve individual and collective goals [29,30]. According to Wooldridge [31], an agent is “a computer system capable of autonomous action in an environment to meet its design objectives”. Numerous definitions of agents have been proposed worldwide, several of which have been reviewed and synthesised in prior work [32], reflecting the diversity of perspectives within the broader field of agent-oriented computing.

Similarly, numerous attempts have been made to define AI agents [33,34]. According to [34] “AI agents are autonomous technologies, designed to perform tasks, make decisions, and interact with their environment to achieve specific predefined goals, with minimal human intervention”. In contrast to traditional software programmes that follow static, pre-defined logic, AI agents exhibit autonomy, adaptability, and proactive behaviour. They function with limited human oversight, continuously perceive and respond to environmental dynamics, and refine their actions through experience-based learning. Moreover, they engage in purposeful communication—both with human users and with other agents—to coordinate tasks and share knowledge, reflecting the social dimension of intelligent systems. As noted in [35], “unlike generative AI, AI agents can interact with their environment to perform tasks for users”. These characteristics are well established in the agent-oriented and artificial intelligence literature [36] and constitute the foundation for intelligent, context-aware architectures. When augmented with the advanced language understanding and generative capabilities of Large Language Models, such agents acquire enhanced interpretive, reasoning, and interaction capabilities that substantially extend their practical applicability in complex, real-world settings [29,36].

According to [37], agents and Multi-Agent Systems have been identified as effective solutions for addressing multiple challenges that emerged in the process of digitalisation of healthcare services, including coordination across heterogeneous components, scalability, and adaptability to dynamic clinical workflows. These characteristics make MAS particularly suitable for privacy-sensitive assisted systems, where responsibilities such as data handling, consent enforcement, reasoning, and auditing must be clearly separated yet tightly coordinated. Thus, a MAS architecture allows privacy responsibilities to be operationalized as autonomous agents with constrained scopes, reducing the attack surface and improving traceability.

3. Materials and Methods

This paper adopts a Design Science Research methodology to systematically design, implement, and evaluate a Privacy-by-Design multi-agent architecture for AI-assisted autism caregiver support. The DSR approach was selected because it enables the development of innovative artefacts that bridge theoretical constructs and practical applications in complex socio-technical contexts such as digital health. Consistent with the Level 1 artefact category, the research focuses on the design and validation of a situated architectural instance rather than a generalised framework.

The primary objectives of the research are as follows:

-

Develop a conceptual multi-agent architecture that separates and assigns specific roles (e.g., user interface, data management, AI analysis, consent, security), thereby enabling enhanced control over data access and the implementation of privacy policies at the component level.

-

Define an informed and transparent consent model integrated within the architecture, allowing caregivers to express and modify their preferences regarding data collection and usage in a clear and accessible manner, while ensuring full compliance with GDPR requirements for transparency and data subject rights.

-

Integrate emerging AI technologies—such as Large Language Models with Retrieval-Augmented Generation, Explainable AI (XAI) algorithms, and differential privacy methods, in a manner that enhances system functionality while simultaneously minimising data exposure. For example, local AI components can provide context-aware recommendations based on locally processed information, thereby preventing sensitive data from being sent to external cloud services.

-

Conduct a conceptual evaluation of the proposed design to assess its robustness, scalability, and practical applicability, while identifying key directions for future implementation and research.

This section outlines the methodology used to design, build, and evaluate the proposed PbD MAS. The focus remains on compliance, security, and clinical interoperability gaps highlighted in the preceding analysis. The section defines the core architectural principles and the implementation workflow of the MVP used for empirical validation.

At the core of the system design is a privacy-aware, modular multi-agent architecture. The proposed PbD MAS leverages MAS properties (modularity, isolation, inter-agent communication) to operationalise PbD principles including data minimisation, purpose limitation, and accountability. Each agent performs a clearly defined role and interacts with other agents through standardised protocols under strict data governance rules. This functional decomposition ensures that responsibilities such as monitoring, data management, interpretation, recommendation, explanation, and consent validation are delegated to specialised agents. The architecture supports clear reasoning, simplified auditing, and modular extension. Each agent has a limited and well-defined function, which improves system transparency and control. Core PbD principles are applied throughout the design. Agents access only the data required to fulfil their designated role, in accordance with the principle of data minimisation. Access control is enforced dynamically using Role-Based Access Control (RBAC), with user roles such as caregiver or specialist determining permissible operations. Any secondary use of data requires verified, purpose-specific consent, enforced through structural constraints within the system. Each agent operates in isolation with a well-defined task, such as monitoring, recommending, or auditing, thereby enabling traceability and role-based accountability.

While this paper does not claim full adherence to the complete DSR lifecycle, particularly with respect to the demonstration and longitudinal evaluation phases, it contributes a functionally grounded and theoretically justified artefact. The contribution aligns with Gregor and Hevner’s classification of Level 1 design science outputs [38], which characterises artefacts as situated implementations. The proposed design is justified by methodological transparency, integration of domain-specific knowledge, responsiveness to user requirements, and alignment with regulatory and ethical frameworks, including the GDPR and responsible AI practices [29].

These architectural choices prioritise deterministic behaviour, traceability, and policy-driven control to support auditability and regulatory compliance in caregiving contexts.

Non-Functional Requirements: Given the sensitivity of personal data processed in assisted tools for caregivers of children with ASD, the architecture prioritises privacy, auditability, explainability, and compliance with legal and regulatory frameworks such as the GDPR [24] and the AI Act [25]. In addition, technical requirements such as scalability, fault tolerance, and interoperability ensure system reliability across diverse use cases.

Table 1. Non-functional Requirements of the privacy-aware MAS.

Non-Functional Requirements	Description
Privacy	All components must apply data minimisation, pseudonymisation, and encryption [24]. Agent-level access is strictly conditional on verifiable, purpose-specific consent.
Performance	Agent responses must be completed within ≤500 ms under normal operational load. End-to-end coordination across the message bus should not exceed 2 s [39,40].
Scalability	The architecture must support horizontal scaling of stateless agents using container orchestration platforms.
Auditability	All access events, policy checks, and agent outputs must be recorded asynchronously via an immutable audit trail. Logs should support traceability and forensic analysis [25].
Interoperability	The system must expose RESTful APIs, HL7 FHIR (for clinical integration), and stable agent-to-agent interfaces for context exchange.
Explainability	In assisted systems for caregivers of children with ASD, outputs must be explainable in a way that is both human-interpretable and consistent with the system’s internal logic. To meet this requirement, the architecture employs symbolic, rule-based explanations generated locally by the XAI Agent, avoiding reliance on post hoc approximation methods. This design supports transparency and auditability, in line with the requirements for trustworthy AI [25], and mitigates concerns about the opacity and low fidelity of black-box explanation techniques [41].
Security	Communication must be secured using TLS 1.3 [42], mutual agent authentication, and encrypted storage for all secrets and personal identifiers. (ISO/IEC 27001:2022 [43]).
Deployment Portability	The system must be deployable in both cloud-native and on-premises environments, with no reliance on external third-party storage or analytics services.
Fault Tolerance	Upon agent failure, orchestration must trigger retries or reroute tasks without data loss. Message processing must be idempotent and state-agnostic.
Compliance Readiness	The system must conform to regulatory obligations (e.g., GDPR, EU AI Act, ISO/IEC 27701 [44]).

summarises the principal non-functional requirements derived from these considerations.

Operational and compliance specifications delineate the system’s boundaries and compliance parameters across deployment settings. All data processing is governed by signed, versioned policies issued by the policy authority. Each processing request includes a trace identifier (trace_id), the active policy version (active policy_version), and, where applicable, a consent version (consent_version). Personal data are processed only when explicit; purpose-specific consent is present and after successful minimisation and data loss prevention checks. If no lawful basis exists or if required safety controls are unavailable, the system defaults to a Knowledge Base (KB)-only operational mode.

Identity and access are managed through standards-based authentication and least-privilege, purpose-scoped authorisation. Inter-service communication is secured using cryptographic and organisational safeguards [45,46]. Observability is integrated through distributed tracing and append-only, minimised audit logs. Specialised agents operate under the coordination of a central Policy Control Plane (PCP) and communicate via a shared message bus. Each agent is assigned a clearly defined functional role and operates under version-controlled policies and consent parameters, enforcing least privilege, purpose limitation, and data minimisation. The architecture adheres to core PbD principles, including explicit consent, explainability, reproducibility, and graceful degradation [24,25,47,48]. When personalisation is not permitted or when required services are unavailable, the system defaults to KB-only responses.

Figure 1 illustrates the agents’ relational structure and communication flows, which enforce role scopes, consent rules and DLP filters.

A central Policy Control Plane, implemented using a policy-as-code approach [49], distributes signed and version-controlled policies (as illustrated in Figure 1) to all agents and enforces role scopes, consent rules and DLP filters, defined as rule sets designed to prevent unauthorised data disclosure. Agents communicate primarily through a decoupled message bus (depicted in green in Figure 1), implementing a publish–subscribe (pub/sub) model. This mechanism supports asynchronous interactions with trace_id and policy_version propagation.

Three specialised agents support bidirectional request/response flows over predefined topics: the RAG Agent (agent.rag.{req|resp}), the Chat Agent (agent.chat.{req|resp}), and the XAI Agent (agent.xai.{req|resp}). Consent validation operates synchronously via HTTP or gRPC and is not routed through the message bus.

All agents emit asynchronous audit events to a dedicated audit subsystem, as shown in Figure 1. Audit records are minimised by design, using hashed identifiers, coarse timestamps, and event sampling to reduce re-identification risk.

Personal data flows are explicit, consent-gated, and strictly constrained, as illustrated in Figure 1:

-

The Consent Agent provides only policy metadata (policy_version, consent_version, obligations) to the Security/DLP Agent.

-

The Security/DLP Agent transfers a minimised payload to the Chat Agent.

-

The Security/DLP Agent sends PII-safe rationales to the XAI Agent, meaning that the justifications for XAI-related actions are processed to ensure that no Personally Identifiable Information (PII) is included in the transmitted content.

These flows are designed to protect sensitive attributes while preserving functional utility for caregivers. Agents are organised across two trust zones based on data sensitivity. In the non-personal data zone, the RAG Agent retrieves evidence from a curated KB. In the personal data zone, the Consent Agent enforces purpose-specific, versioned consent; the Security/DLP Agent applies context minimisation [24] and output filtering; the Chat Agent generates AI responses only when legally permitted; and the XAI Agent produces PII-safe explanations aligned with the underlying recommendation logic [25].

The processing sequence—Authorise → Consent → DLP → Retrieve/Personalise → XAI → Audit—operationalises PbD and enables graceful degradation through KB-only responses when personalisation is not permitted or components are unavailable.

Layered Architecture. Figure 2 presents a layered architecture that separates responsibilities according to both functional roles and trust boundaries. Privacy, safety, and auditability are treated as core system properties. The architecture is technology-agnostic and adopts a fixed-policy, non-adaptive control model. All components operate under PCP issued policies.

The visual encoding distinguishes interaction types as follows:

-

Purple lines represent policy distribution and access control.

-

Green lines denote asynchronous publish/subscribe communication.

-

Blue lines indicate synchronous request–response interactions (gRPC/HTTP).

-

Red lines mark personal data flows gated by consent and minimisation.

-

Brown dashed lines represent asynchronous audit events.

These visual markers represent enforceable runtime invariants that are validated through tracing and audit mechanisms to ensure conformance with PbD principles and regulatory requirements.

The User Interface (UI) layer provides RBAC for all users. It includes a dashboard for managing data subject rights (opt-in/out, data export, deletion). All ingress traffic is protected by Transport Layer Security (TLS) 1.3 [42] ensuring confidentiality and data integrity against interception and tampering. Authentication is implemented through OpenID Connect (OIDC)/OAuth 2.0 using short-lived tokens to enhance security [50,51].

Clients do not store sensitive data unless explicitly permitted. When local storage is required, all data are encrypted and bound to the device’s secure keystore. User interface components are filtered according to the active role and consent scope, thereby enforcing purpose limitation at the point of use.

Control and Orchestration Layer mediates system interactions. The API Gateway handles TLS termination, request validation, and trace propagation, with each request carrying a trace_id header and scopes validated by an RBAC service against policies issued by the PCP. The Orchestrator coordinates the processing flow:

Authorise → Consent → Minimise (DLP) → Retrieve (RAG) → Personalise → Explain (XAI) → Deliver

If the preconditions for personalisation are not satisfied, the Orchestrator falls back to a KB-only pathway and informs the user. The message bus handles asynchronous communication with retries and backpressure; synchronous requests are restricted to low-latency control paths. The Orchestration logic is non-adaptive and policy pinned, and it does not trigger behaviourally driven actions. Although adaptive orchestration was initially considered to increase flexibility, it was ultimately rejected in favour of deterministic orchestration, whereby identical inputs consistently yield identical outputs. This design choice simplifies compliance auditing and reinforces legal accountability. Prior research on explainable AI indicates that stakeholders, particularly auditors and caregivers, are more likely to trust systems that exhibit predictable and transparent behaviour [52,53]. While this approach may reduce optimisation opportunities, it strengthens auditability and aligns with the transparency requirements of GDPR (Accountability) [24] and the EU AI Act (Logging and Traceability) [25].

Knowledge and Non-Personal Data Layer supports information retrieval without processing personal data. The curated KB stores validated content with metadata (source, licence, freshness). The RAG service performs semantic search with cited results. All KB modifications are recorded immutably to ensure data provenance and traceability. This layer provides useful functionality without exposing personal data and ensures the system remains operational even when components fail.

Personal Data Layer is responsible for consent-gated processing of identifiable information. The Consent Service manages revocable, purpose-bound decisions with versioning and audit support. Personal data are encrypted and accessible only through controlled interfaces. Ingested data is pseudonymised and minimised at source. A rule-based Analysis Agent operates within this trust zone exclusively on derived signals produced by the monitoring pipeline; it performs no statistical prediction, emitting only policy relevant alerts. Personalisation is executed solely when permitted by active consent and RBAC rules. Aggregate analytics employ fixed-query differential privacy under ε-budgets, maintained separately from interactive services to preserve predictability.

Security and Observability Layer enforces system-wide safeguards. The DLP service applies input minimisation and output filtering, including checks on explanations. Keys and secrets are managed through environment-isolated configuration with restricted access controls [54]. Data at rest are encrypted (e.g., Advanced Encryption Standard with Galois/Counter Mode—AES-GCM), and all connections use Mutual TLS (mTLS). The Audit subsystem records append-only, hashed logs with coarse-graining timestamp and sampling. Each event is tagged with the corresponding policy_version and, where applicable, consent_version.

Each horizontal layer defines a trust boundary. Transitions from non-personal to personal layers require explicit consent and confirmed minimisation. All inter-layer calls carry trace_id, policy_version, and consent_version. Requests with missing or outdated context are rejected. Failure cases are handled explicitly. If consent or DLP checks fail, the system defaults to a KB-only path and records the fallback event. If RAG functionality is degraded, cached or hedged queries reduce latency. If a KB version is invalid, the controller reverts to the most recent stable snapshot. The user interface reflects current state (e.g., “personalisation unavailable—general guidance shown”), thereby maintaining user trust and system utility. This layered separation also supports the explainability requirement. Aggregate outputs are generated using fixed query templates with defined ε-budgets. The system avoids post hoc approximations of opaque models, maintaining consistency between internal logic and the explanations presented to users. The layered architecture implements PbD through structural and policy-based constraints. Data minimisation is enforced by default. Most requests are handled entirely within the non-personal layer. Personal data are accessed only when consent is active and features have been minimised. Purpose limitation and least privilege are ensured through signed policies, RBAC scopes, and strict validation of context at every processing step. Explainability and accountability are integral to the design. The RAG Agent retrieves cited evidence, while the XAI Agent generates reproducible, symbolic outputs filtered for PII. All actions are logged to support auditing and compliance. The result is a system that provides functional value under constrained conditions, degrades safely when requirements are unmet, and remains auditable, predictable, and aligned with regulatory and ethical standards.

Agent Typology and Control Framework. The proposed architecture is organised around specialised agents, each assigned a narrow-defined mandate and operating under the principle of least privilege. This design minimises the overall attack surface, simplifies compliance verification, and ensures that accountability can be attributed to individual components. The PCP functions as the central governance authority, distributing signed and version-controlled policies to all agents. This mechanism ensures that inter-agent interactions remain consistently regulated and that changes in regulatory or organisational requirements are traceable throughout the system lifecycle. The Consent Agent enforces purpose-bound consent by validating requests against HL7 FHIR Consent resources. For each authorised interaction, it appends policy_version and consent_version metadata, embedding compliance with regulated legal requirements directly into operational workflows. The Security/DLP Agent safeguards the system by detecting and redacting PII, minimising payloads, and generating PII-safe rationales. It enforces deny-by-default access controls and isolates high-risk services, such as code execution modules, thereby preventing data leakage and mitigating adversarial exploitation. The RAG Agent manages access to curated, version-controlled knowledge bases through policy-scoped queries. It integrates provenance logging and attaches citation guarantees, reducing hallucination risks and strengthening the factual basis for downstream explainability. The Chat Agent provides contextual recommendations derived from policy-validated and DLP-filtered inputs. Within this architecture, SLMs serve as the default reasoning engine for tasks involving personal data, thereby supporting data minimisation principles and enabling sub-second response times. The invocation of LLMs is restricted to pseudonymised, knowledge-based artefacts, and occurs only when tasks require reasoning capabilities beyond those of SLMs. The allocation between SLM and LLM follows a deterministic routing policy governed by sensitivity, task complexity, latency, and faithfulness checks, with each routing decision rendered auditable through trace identifiers and policy metadata. The Orchestrator deterministically routes inputs to SLMs or LLMs by sequentially applying sensitivity, task complexity, latency/resource, and faithfulness gates. It defaults to SLMs for personal or low-complexity tasks within strict latency bounds and escalating to LLMs only when inputs are pseudonymised artefacts, tasks demand higher reasoning capacity, or SLM outputs fail accuracy or evidence-alignment checks [55]. The XAI Agent transform decision traces into human-readable explanations. By generating symbolic, rule-based rationales and evidence chains from CloudEvents and retrieval outputs, it avoids opaque black-box justifications and reinforces transparency and stakeholder trust [56]. The Audit Agent enables system-wide accountability by asynchronously recording all events in CloudEvents format. Each event is enriched with signed metadata, including trace_id, policy_version, and consent_version, enabling tamper-evident logging that supports both real-time monitoring and post hoc Data Protection Impact Assessments (DPIA) [47]. Finally, the message bus facilitates inter-agent communication through a decoupled publish/subscribe mechanism. It provides scalability, fault tolerance, and resilience while maintaining observability through W3C Trace Context propagation.

Minimum requirements. All components must satisfy the following constraints: TLS 1.3 exclusively, restricted to TLS_AES_128_GCM_SHA256 or TLS_CHACHA20_POLY1305_SHA256 in accordance with NIST SP 800-53 AU and IETF RFC 8446 [42,57,58]; mTLS for Agent-to-Agent (A2A) and gRPC interactions, consistent with the OAuth 2.0 mutual TLS profile [51]; OAuth 2.0 BCP with least-privilege scopes, access-token Time to Live (TTL) ≤ 5 min, and no refresh tokens for server-to-server interactions [50]; certificate and key rotation every ≤ 90 days [59]; NATS JetStream max_age ≤ 24 h for minimised PII (7–30 days for non-PII) [60]; Kafka retention.ms ≤ 24 h for PII, with audit topics compacted and retained 365 days without PII [61]; Redis Streams trimmed to 24 h where PII exists [62]; and fail-closed enforcement if policy_version, consent_version, or purpose_id are missing [63,64]. Retention and TTL constraints for message buses are defined in the Security and Retention Profile (Appendix A).

The PCP governs protocol usage by binding each data flow to policy, consent, and purpose constraints, ensuring that transport-layer decisions remain auditable and legally compliant.

Deployment. Containerisation and Namespace Isolation. The deployment of the privacy-aware MAS is designed to combine modular scalability with strict compliance guarantees. The architecture is implemented in a containerised environment orchestrated by Kubernetes [65], which provides automated scheduling, scaling, fault recovery, and namespace isolation [66]. Each agent (Orchestrator, Consent and Policy Control, DLP, RAG, Chat, XAI and Audit) is deployed in an independent pod, while supporting subsystems enforce cross-cutting requirements for policy management, secure communication, and data protection.

Personal and Non-Personal Zones. The secure zone is protected by Kubernetes Network Policies, which restrict inter-namespace traffic and prevent personal data flows from being routed into non-personal domains [67]. In this scenario runtime isolation is enforced with Pod Security Standards and kernel-level profiles, reducing the risk of container breakout attacks [68]. All processing involving personal data is confined to a secure zone, where low-latency reasoning tasks are executed. Personal data never leaves this zone in raw form: identifiers are removed or minimised before artefacts are transferred to the non-personal domain. This design ensures strong isolation and direct alignment with data minimisation principles. The non-personal zone hosts LLM escalation, knowledge retrieval, recommendation, and XAI Agents. LLMs process only pseudonymised artefacts or non-personal knowledge. SLMs handle personal data solely within the secure zone, under consent and data minimisation controls. The PCP distributes signed, versioned policies, and every message carries a trace_id, policy_version and consent_version, validated by each agent. This mechanism enforces purpose-bound processing and produces a reproducible evidence trail that supports system-wide accountability [24,25,63,64].

Communication Layer. A hybrid message bus underpins inter-agent communication, balancing durability, latency, and control. Apache Kafka provides durable, auditable streams [69]; Redis Streams supports low-latency ephemeral channels with short retention; and NATS JetStream carries lightweight control signals [60]. This layered design ensures operational resilience while supporting privacy-driven data minimisation.

Service Mesh. A service mesh (Linkerd at baseline [70], Istio at scale [71]) intercepts all inter-agent traffic through sidecar proxies [72]. It enforces mutual TLS, context propagation, retries, and policy checks at the network layer, while exporting telemetry via W3C Trace Context [63] and CloudEvents [64]. This approach provides uniform observability and fault isolation without modifying agent logic.

Vault Subsystem. A dedicated Vault subsystem manages cryptographic material. It issues short-lived OAuth2/OIDC [51] tokens, performs automatic TLS certificate rotation, and records lifecycle events. This centralised approach reduces exposure windows for secrets and aligns with controls on key management [43].

RAG Subsystem. RAG is supported by a Vector Database (VDB) that enables Approximate Nearest Neighbour (ANN) search across embeddings. For small and medium deployments, embedded solutions such as pgvector or FAISS [73] are sufficient, while large-scale workloads use dedicated engines such as Milvus or Qdrant [74]. This subsystem delivers evidence retrieval with provenance guarantees. Personal embeddings are stored exclusively in the secure zone, while the non-personal VDB manages only pseudonymised artefacts, maintaining strict separation between sensitive and non-sensitive data [75].

Event Logging and Compliance. All agents emit CloudEvents [64] enriched with compliance metadata, which are consolidated into tamper-evident logs. This ensures traceability, supports regulatory audits, and provides a verifiable accountability layer across the entire system.

Fallback Strategy. If DLP or consent validation fails, the system defaults to KB-only mode, preventing any personal data processing outside lawful conditions. If RAG services degrade or fail, the system returns cached responses from the most recent stable KB snapshot. If the Consent Agent, Security/DLP Agent, and Chat Agent become unavailable, processing continues exclusively through the non-personal path, with outputs restricted to generalised guidance derived from the KB [25,26,63,64].

Audit and DP. The Audit Agent incorporates a logically separated analytics tool that applies OpenDP/SmartNoise [76] under differential privacy. The deployment strategy ensures graceful degradation, with fallback to generic retrieval when personalised agents are unavailable, fault tolerance through Kubernetes rescheduling and message bus replay, and comprehensive observability. All fallback mechanisms follow a fail-closed posture: if required metadata (consent_version, policy_version) is missing or invalid, personal data processing is blocked, and KB-only responses are returned.

Observability and Tracing. The proposed MAS integrates a comprehensive observability subsystem to ensure that operational behaviour remains transparent, auditable, and diagnosable in real time. Tracing is implemented using OpenTelemetry, with Jaeger as the backend. The W3C Trace Context standard ensures that spans originating in the Consent Agent propagate consistently across downstream agents, enabling reconstruction of end-to-end workflows. Retention policies limit logs to compliance-mandated durations. Non-PII metadata is stored for up to 365 days. PII is excluded from observability data by design [24,25,47,64]; detailed mappings are provided in Appendix A. Each agent within the MAS is deployed as an independent Kubernetes pod, with strict namespace isolation and integration into the hybrid message bus. The Orchestrator, implemented as a FastAPI service connected to Kafka and NATS, coordinates the lifecycle of other agents and enforces orchestration policies. The Consent Agent, a microservice handling JSON-LD consent records [77], enforces runtime consent, processes revocation requests, and applies purpose limitation; its events are routed through Kafka and Redis adapters [78]. The Audit Agent, built on OpenTelemetry [79] and Elasticsearch [80] (scalable search and storage engine for logs and events), Logstash [81] (pipeline for log collection and transformation), and OpenSearch Dashboards [82] (visual interface for querying and dashboards). It collects and signs audit logs, stores CloudEvents in Kafka. The DLP, equipped with Named Entity Recognition (NER) models and a redaction engine (Stanza [83]), performs pseudonymisation and minimisation prior to storage or retrieval of personal data. Its access to the VDB is restricted through RBAC policies. The RAG Agent uses frameworks such as LangChain [84] with Qdrant [85] to perform knowledge retrieval under privacy-preserving filters. It falls back to KB-only responses when metadata such as policy_version or consent_version are missing or invalid. The Chat Agent, implemented as a ML service (Framework ML: scikit-learn [86]), delivers personalised outputs through Redis and NATS channels but reverts to KB-only outputs when consent or DLP validation fails. The XAI Agent integrates libraries such as LIME [87] to generate explanations and enforce Human-in-the-Loop (HITL) reviews, recording all explanation events as CloudEvents. The RBAC Service, integrated with a Vault service (HashiCorp Vault [54]), manages secure generation, rotation, and revocation of cryptographic material, and distributes signed policy manifests across the system. Observability is implemented as a cross-cutting subsystem that combines Grafana dashboards [88] with Jaeger tracing [89] to provide unified monitoring of metrics, logs, and traces to support Service Level Agreement (SLA) compliance and fault diagnosis.

The layered model integrates Orchestrator hub coordination, Kafka-based audit trails, Redis low-latency exchanges, and NATS control signals, balancing compliance with resilience and scalability.

Threat modelling and validity threats. The LINDDUN framework [90] is applied to the architecture’s concrete Data-Flow Diagrams (DFDs), enabling linking of identified threats to controls and to verifiable evidential artefacts of the MAS (Appendix C).

Each identified threat is linked to a control and to a verifiable artefact, such as a signed CloudEvent containing traceparent, policy_version, and consent_version when applicable, a consent snapshot, a DLP rule_id with model_version, or a differential privacy ledger entry [47,63,64]. Data retention is bound to transport class: Redis stores personal data for ≤24 h, Kafka retains non-PII for 365 days, and NATS is used for ephemeral control traffic [60,61,69,91].

Assumptions. The analysis assumes a controlled deployment with mutual TLS across all communication [92], rotating short-lived certificates [59], preserved vault integrity [43], clock synchronisation across nodes [93], and an active DLP subsystem.

Adversary model. Three categories are considered: external attackers targeting network interfaces and APIs [46], authorised insiders with curious access [48,75], and third-party tool or service providers [48]. Out of scope are endpoint compromise, operating-system root-level attacks, and hardware backdoors.

Method, scope, and traceability. DFDs include sensitivity labels and transport/retention assignments. Each element is evaluated against the seven LINDDUN categories and all identified threats are recorded in a traceability register (

Table 2. The LINDDUN categories applied to the proposed architecture.

LINDDUN Category	Threat Locations	Controls	Evidence	Bibliographic Refs
Linkability	Consent Agent; telemetry export paths	Purpose-scoped consent; ingress minimisation; timestamp coarsening; session pseudonym rotation	Consent indexes; signed audit events (Appendix D)	[94,95]
Identifiability	Ingest; retrieval; vector database	Pseudonymisation at source; inline DLP (NER + redaction); RBAC on vector databases	DLP redaction logs; VDB access audits	[96,97]
Non-repudiation	PCP; audit Kafka topics	Signed and versioned policy manifests; cryptographically signed CloudEvents; short-lived credentials	Signed manifests; Vault audit trails	[69,98]
Detectability	Monitoring channels; heartbeat signals	Suppression of presence flags without consent; group aggregation; calibrated noise	Masked monitoring exports; detectability probe records	[88]
Disclosure	RAG paths; LLM escalation paths; API surfaces	Rate limiting; query auditing; output sanitisation; DP analytics with privacy accountant	Red-team reports; privacy-accountant ledger	[99]
Unawareness	Missing or opaque consent flows	Purpose-specific consent records; synchronous Orchestrator validation; fail-closed behaviour	Consent DB snapshots; Orchestrator validation logs	[24,95,100]
Non-compliance	Policy conflicts; routing errors	Deterministic PCP pre-deployment checks; policy resolution trace recording	PCP resolution logs; rejected event traces	[49,101]

). The register links DFD element, LINDDUN threat, controls to evidential artefact. It employs a standardised vocabulary based on formal taxonomies, supports automated cross referencing to DFD artefacts, and provides input for evidence extraction and audit replay [90]. References to Appendix C and Appendix D point to supporting artefacts. These appendices exemplify the artefacts that substantiate the conceptual threat assessment. Appendix C presents the reproducibility-bundle schema together with a representative export comprising an audit event, consent snapshot, DLP entry, PCP resolution, VDB provenance, and privacy-accountant excerpt. Appendix D documents the complete LINDDUN mapping, qualitative risk scores, and the validation checklist, including sensitivity analyses, PCP continuous-integration tests, and portability smoke tests.

Within the LINDDUN categories of Disclosure and Content Unawareness, hallucination is treated as a combined disclosure and misinformation risk. Mitigation strategies rely on the systematic tracking of trace_id, policy_version and consent_version tracking, DLP-based minimisation, RAG provenance records, and fail-closed. On detecting deviations, the system triggers auditing and returns a non-personalised fallback response.

Validity threats. Construct validity risks arise from proxy measures (timestamp coarsening, hashing, privacy budget in differential privacy). Internal validity is affected by policy drift [102]. External validity depends on middleware defaults (Kafka, Redis, NATS) [69,78,103]. Conclusion validity is contingent on the availability of a complete reproducibility bundle (signed audit event, consent snapshot, DLP entry, PCP resolution, VDB provenance data) [76,98,102]. The complete reproducibility-bundle schema and the sample artefacts used in the assessment of conclusion validity are presented in Appendix C. The full LINDDUN mapping together with the associated validation checklists is provided in Appendix D.

DFD identifiers. Each element has a stable dfd_id of the form DFD-L<level>-<component>-<seq>. L1 denotes context diagrams; L2 identifies detailed sub-flows [90]. The complete registry and version history are provided in Appendix D.

Evidence captures must be both deterministic and minimal. For each trace, only the following artefacts should be collected: (i) signed audit CloudEvent [64], (ii) consent snapshot [95], (iii) DLP/redaction entry [104], (iv) PCP resolution [49], (v) VDB provenance [97], and (vi) privacy-accountant excerpt [76]. All artefacts must include canonical attributes (traceparent or mapped trace_id [63], policy_version, consent_id, consent_version, decision/action, timestamp) as well as provenance metadata [43]. Where raw content cannot be shared, redacted copies should be provided alongside hash commitments [102]. A sampled trace should include: the signed audit event with its offset; the corresponding consent database row or snapshot; the DLP log line with rule_id, model_version, and action; the PCP-resolution log with applied policy_version; the VDB retrieval_provenance file for the relevant query_id; and the privacy-accountant ledger excerpt. This bundle supports DPIA validation and remains compliant with GDPR requirements, provided that retention guarantees are enforced [24,43,105].

Comparison with other frameworks. We evaluate the proposed architecture against alternative frameworks using seven criteria (C1–C7) (

Table 3. Evaluation criteria for framework comparison.

Criterion	Evaluation Focus	Standards/Guidance	Verification Checks
C1 Governance and audit	Accountability, traceability, and security governance	ISO/IEC 27001 (ISMS); ISO/IEC 27701 (PIMS); NIST SP 800-53 AU controls	ISMS/PIMS scope defined; Statement of Applicability; mapping of log events to NIST AU controls; log retention and tamper-evidence procedures
C2 Consent orchestration	Lawful basis, revocation, runtime enforcement	ISO/IEC TS 27560 [77]; GDPR; EDPB guidance	JSON/JSON-LD consent records; revocation workflow; synchronous runtime enforcement
C3 Clinical interoperability	Integration with clinical systems	HL7 FHIR	Published Capability Statement; successful profile conformance tests
C4 Privacy-enhancing technologies (PETs)	Engineering of privacy-by-design	ENISA Data Protection Engineering guidance	Documented PET selection; architectural integration; implementation evidence
C5 Edge performance and reliability	Deployability in care settings	ISO/IEC 25002:2024 [106]	Latency bounds; offline operation; uptime targets; resource usage; error recovery
C6 Local explainability (HITL)	Caregiver oversight and trust	Human-in-the-loop principles	Explicit HITL decision points; local explanations available to caregivers
C7 Federated lifecycle	Personalisation without centralisation	Federated learning engineering practices	Client orchestration; aggregation; update rollout; rollback mechanisms

) derived from established international standards and regulatory guidance. The criteria cover governance and auditability, consent orchestration, clinical interoperability, privacy-enhancing technologies, edge performance, local explainability, and federated lifecycle management. Each criterion is assessed using verifiable technical and procedural controls aligned with GDPR and EU AI Act accountability requirements.

Privacy-preserving analytics in healthcare have shifted from centralised data lakes to distributed paradigms such as “algorithm-to-data” approaches and federated learning. Contemporary frameworks illustrate this transition: NVIDIA FLARE [20] integrates audit logging and PETs [20]; Substra applies a “data never leave the node” model with ledger-backed traceability [21]; DataSHIELD enables non-federated assign/aggregate statistics. Agentic enablers such as Microsoft Healthcare Agent Orchestrator [107] and Model Context Protocol (MCP)-FHIR connectors bridge multi-agent workflows to FHIR endpoints [108]. Despite these advances, two gaps remain in clinical assisted settings: (1) limited production-grade FHIR conformance and (2) the absence of consent orchestration aligned with ISO/IEC TS 27560 [77]. ENISA further emphasises that PETs should be integrated as engineered controls within governance frameworks rather than appended in an ad hoc manner. The proposed architecture addresses these gaps by combining a secure MAS (supporting consent management, audit/DLP, local explainability) with a hybrid message bus and a SMART-on-FHIR perimeter, encapsulating FL runtimes and non-FL distributed analytics as agents. This design preserves the strengths of PET- and FL-based approaches while resolving critical governance and conformance gaps (C2–C3–C6), thereby supporting deployment in autism-care settings. A detailed criterion-based comparison (C1–C7) is presented in Appendix B.

Experimental setup. The operational validity of the proposed PbD MAS was assessed through a structured empirical evaluation of complete Retrieval-Augmented Generation pipeline. The evaluation employed two complementary evaluation datasets (combined n = 250), covering clinically grounded knowledge and naturalistic caregiver communication. To assess practical feasibility, all experiments were conducted on consumer-grade edge hardware. Specifically, the system was deployed on a MacBook Pro M4 with 16 GB RAM, running a containerised microservices stack and a local language model runtime.

The system implements a modular multi-agent architecture composed of narrowly scoped agents, supporting PbD principles and end-to-end traceability. Processing begins with a DLP-first pipeline, in which caregiver or clinical text is processed by a dedicated Security/DLP Agent for pseudonymisation and personal data redaction. Raw identifiers are not stored; only sanitised text is subsequently chunked and indexed in the vector database by the RAG Agent. Consent enforcement, runtime policy checks, and residual PII validation operate across both retrieval and generation stages. Audit logging and distributed tracing provide accountability and traceability aligned with GDPR and EU AI Act requirements.

Scenario Evaluation. An MVP of the proposed system was evaluated under controlled conditions. In addition to the technical assessments of data processing and retrieval, reported in the Results section, we designed and implemented a representative MAS use case. The scenario models secure remote collaboration between a caregiver and a specialist, such as a therapist or special education teacher, who must review home-based progress. The use case verifies that the distributed agent architecture safeguards personal data while maintaining the required communication flow. The scenario covers an end-to-end cycle of sharing child’s observation records, from data ingestion to authorised access and consent revocation. A caregiver uploads a child’s observation note. The Security/DLP Agent processes the note using three detection layers. Regular expression (Regex) detects fixed patterns. NER from Presidio (2.2.360) identifies structured entities. A context-sensitive detector loads entries (e.g., the child’s name) from a local SQLite (3.50.4) context and marks them as PII. The DLP engine produces deterministic placeholders using salted SHA-256 hashes. A dual storage model in the note_registry table stores (i) the original text in encrypted form, (ii) an anonymised version for retrieval, and (iii) pii_spans_json to enable reconstruction when authorised.

The RAG Agent stores anonymised child’s observation records in Qdrant (v1.16.3). The retrieval strategy combines dense embeddings with sparse BM25 search. Maximal Marginal Relevance (MMR) filters the combined set. To prevent cross-user leakage, separate collections are maintained for each caregiver. Specialist access is managed through a token-based mechanism. After admin approval, the system issues a Universally Unique Identifier (UUID) token which is recorded as “active” in the assignments table. When a specialist accesses a record under an active token, the system reconstructs the original view by inserting values from the child context into the anonymised text. Once the token status becomes revoked, reconstruction is blocked and only the anonymised text is exposed. The Chat Agent performs local inference, using LM Studio (0.3.39—Build 2), to avoid cloud-based exposure.

The agent merges child’s observation records from the rag_collection with objective guidance retrieved from the global_knowledge collection. A system prompt constrains the agent to an Applied Behaviour Analysis (ABA) therapy assistant and explicitly prohibits diagnostic content. The MCP gateway performs consent and DLP checks prior to generating any output. All activities are logged by the Audit Agent to ensure GDPR-aligned accountability and compliance with EU AI Act traceability requirements.

Evaluation methodology: The empirical evaluation of the proposed Privacy-by-Design Multi-Agent System employs the RAGAs (Retrieval-Augmented Generation Assessment) framework proposed by Es et al. (2024) [109], adapted for deployment with locally hosted LLMs to ensure reproducibility and eliminate dependencies on external API services. Two domain-specific evaluation corpora were developed to assess system performance across complementary linguistic and informational contexts.

The DSM-5 Knowledge QA Dataset (n = 100) consists of question–answer pairs derived from the Diagnostic and Statistical Manual of Mental Disorders 5th Edition [110] and evidence-based literature on autism interventions. The questions cover diagnostic criteria, behavioural indicators, therapeutic modalities (including applied behaviour analysis, speech therapy, and occupational therapy) and prognostic aspects. The dataset evaluates retrieval and synthesis of clinically grounded information using medical terminology.

The Caregiver Notes QA Dataset (n = 150) simulates naturalistic communication between caregivers and educational or therapeutic specialists. The notes cover eight behavioural categories, including daily transitions, communication patterns, sensory responses, social interaction, routine adherence, therapy observations, behavioural incidents, and health-related observations. The dataset assesses retrieval performance on informal observational language commonly used in caregiver documentation.

In addition, 30 metadata filter test cases were used to validate access control mechanisms, including single-value filters, OR condition queries, combined filter operations, owner-based restrictions, and edge case scenarios.

The evaluation framework implements 14 metrics organised into four methodologically distinct categories:

(a) 

LLM-as-a-Judge metrics—6 metrics

Answer Relevancy is a core evaluation metric that assesses the extent to which a generated response addresses the original user query. The metric is computed by reconstructing a set of synthetic questions from the generated answer using an LLM and measuring their semantic similarity to the original query embedding:

$$\mathrm{A}\mathrm{n}\mathrm{s}\mathrm{w}\mathrm{e}\mathrm{r} \mathrm{R}\mathrm{e}\mathrm{l}\mathrm{e}\mathrm{v}\mathrm{a}\mathrm{n}\mathrm{c}\mathrm{y}={\displaystyle \frac{1}{n}} \sum _{i=1}^n\mathrm{c}\mathrm{o}\mathrm{s}\left({\mathbf{e}}_{\mathrm{o}\mathrm{r}\mathrm{i}\mathrm{g}\mathrm{i}\mathrm{n}\mathrm{a}\mathrm{l}},{\mathbf{e}}_{{\mathrm{g}\mathrm{e}\mathrm{n}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{d}}_i}\right)$$

where ${\mathbf{e}}_{\mathrm{o}\mathrm{r}\mathrm{i}\mathrm{g}\mathrm{i}\mathrm{n}\mathrm{a}\mathrm{l}}$ denotes the embedding of the original question and ${\mathbf{e}}_{{\mathrm{g}\mathrm{e}\mathrm{n}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{d}}_i}$ represents the embeddings of the reconstructed questions derived from the generated answer. Lower values indicate reduced relevance, reflecting the presence of redundant, incomplete, or off-topic content in the generated response [109].

Faithfulness quantifies the proportion of answer claims that are supported by the retrieved context. The computation follows two steps: (i) atomic claims are extracted from the generated answer, and (ii) each claim is verified against the retrieved context using Natural Language Inference (NLI). Formally:

$$\mathrm{F}\mathrm{a}\mathrm{i}\mathrm{t}\mathrm{h}\mathrm{f}\mathrm{u}\mathrm{l}\mathrm{n}\mathrm{e}\mathrm{s}\mathrm{s}={\displaystyle \frac{\left|C_{\mathrm{s}\mathrm{u}\mathrm{p}\mathrm{p}\mathrm{o}\mathrm{r}\mathrm{t}\mathrm{e}\mathrm{d}}\right|}{\left|C_{\mathrm{t}\mathrm{o}\mathrm{t}\mathrm{a}\mathrm{l}}\right|}}$$

where $C_{\mathrm{t}\mathrm{o}\mathrm{t}\mathrm{a}\mathrm{l}}$ denotes the set of atomic factual statements extracted from the generated answer and $C_{\mathrm{s}\mathrm{u}\mathrm{p}\mathrm{p}\mathrm{o}\mathrm{r}\mathrm{t}\mathrm{e}\mathrm{d}}$ denotes the subset verified as entailed by the retrieved context [109].

Context Precision measures the position-weighted relevance of retrieved documents:

$$\mathrm{C}\mathrm{o}\mathrm{n}\mathrm{t}\mathrm{e}\mathrm{x}\mathrm{t} \mathrm{P}\mathrm{r}\mathrm{e}\mathrm{c}\mathrm{i}\mathrm{s}\mathrm{i}\mathrm{o}\mathrm{n}={\displaystyle \frac{\sum _{k=1}^K(\mathrm{P}\mathrm{r}\mathrm{e}\mathrm{c}\mathrm{i}\mathrm{s}\mathrm{i}\mathrm{o}\mathrm{n}@k \times v_k)}{\sum _{k=1}^K{v}_k}}$$

where $v_k$∈ {0,1} indicates the relevance of the context at rank k, and Precision@k denotes the proportion of relevant contexts in the top-k retrieved results [109].

Context Recall evaluates whether content from the reference answer is attributable to the retrieved context and is defined as:

$$\mathrm{C}\mathrm{o}\mathrm{n}\mathrm{t}\mathrm{e}\mathrm{x}\mathrm{t} \mathrm{R}\mathrm{e}\mathrm{c}\mathrm{a}\mathrm{l}\mathrm{l}={\displaystyle \frac{\left|S_{\mathrm{s}\mathrm{u}\mathrm{p}\mathrm{p}\mathrm{o}\mathrm{r}\mathrm{t}\mathrm{e}\mathrm{d}}\right|}{\left|S_{\mathrm{t}\mathrm{o}\mathrm{t}\mathrm{a}\mathrm{l}}\right|}}$$

where $S_{\mathrm{t}\mathrm{o}\mathrm{t}\mathrm{a}\mathrm{l}}$ denotes the set of sentences in the gold-standard answer, and S_supporteddenotes the subset of sentences that are verified as being supported by the retrieved context [109].

Answer Correctness and Context Relevance are assessed using direct LLM evaluation on a 1 to 5 ordinal scale, measuring factual accuracy against reference answers and alignment between the query and the retrieved context, following the LLM-as-a-Judge paradigm [111].

(b) 

Answer Similarity measures the semantic similarity between generated and reference answers by computing the cosine similarity between their embedding representations:

$$\mathrm{A}\mathrm{n}\mathrm{s}\mathrm{w}\mathrm{e}\mathrm{r} \mathrm{S}\mathrm{i}\mathrm{m}\mathrm{i}\mathrm{l}\mathrm{a}\mathrm{r}\mathrm{i}\mathrm{t}\mathrm{y}={\displaystyle \frac{\sum _{i=1}^{\mathrm{d}}{\mathbf{e}}_{\mathrm{g}\mathrm{o}\mathrm{l}\mathrm{d},i} {\mathbf{e}}_{\mathrm{p}\mathrm{r}\mathrm{e}\mathrm{d},i}}{\sqrt{\sum _{i=1}^{\mathrm{d}}{\mathbf{e}}_{\mathrm{g}\mathrm{o}\mathrm{l}\mathrm{d},i}^2 }\sqrt{\sum _{i=1}^d{\mathbf{e}}_{\mathrm{p}\mathrm{r}\mathrm{e}\mathrm{d},i}^2 }}}$$

where the embedding vectors ${\mathbf{e}}_{\mathrm{g}\mathrm{o}\mathrm{l}\mathrm{d}}$ and ${\mathbf{e}}_{\mathrm{p}\mathrm{r}\mathrm{e}\mathrm{d}}$ are generated using the mxbai-embed-large-v1 embedding model.

(c) 

Information Retrieval Lexical Metrics—4 metrics

Precision@K follows the classical definition in information retrieval [112], measuring the proportion of relevant documents among the top-K retrieved results. Relevance is formalised as a binary predicate based on lexical overlap with the gold-standard answer:

$$\mathrm{P}\mathrm{r}\mathrm{e}\mathrm{c}\mathrm{i}\mathrm{s}\mathrm{i}\mathrm{o}\mathrm{n}@\mathrm{K}={\displaystyle \frac{1}{\mathrm{K}}}\left|\left\{d \in {\mathcal{D}}_K | \mathrm{o}\mathrm{v}\mathrm{e}\mathrm{r}\mathrm{l}\mathrm{a}\mathrm{p}\left(d,gold\right)\ge \theta \right\}\right|$$

where ${\mathcal{D}}_K$ denotes the set of the top-K retrieved documents, and $\theta$ = 0.3 represents the minimum word-overlap threshold. The function $\mathrm{o}\mathrm{v}\mathrm{e}\mathrm{r}\mathrm{l}\mathrm{a}\mathrm{p}\left(d,gold\right)$ computes the proportion of shared significant terms (length > 3, excluding stopwords) between the retrieved context d and the reference answer [112].

Recall@K quantifies the coverage of gold-standard answer content by the retrieved documents:

$$\mathrm{R}\mathrm{e}\mathrm{c}\mathrm{a}\mathrm{l}\mathrm{l}@\mathrm{K}={\displaystyle \frac{|\mathrm{t}\mathrm{e}\mathrm{r}\mathrm{m}\mathrm{s}\left(gold\right)\cap {\mathrm{t}\mathrm{e}\mathrm{r}\mathrm{m}\mathrm{s}(\mathcal{D}}_K)|}{\left|\mathrm{t}\mathrm{e}\mathrm{r}\mathrm{m}\mathrm{s}\left(\mathrm{g}\mathrm{o}\mathrm{l}\mathrm{d}\right)\right|}}$$

where $\mathrm{t}\mathrm{e}\mathrm{r}\mathrm{m}\mathrm{s}\left(\mathrm{g}\mathrm{o}\mathrm{l}\mathrm{d}\right)\cap {\mathrm{t}\mathrm{e}\mathrm{r}\mathrm{m}\mathrm{s}(\mathcal{D}}_K)$ significant lexical units through tokenization, stopword removal, and length-based filtering [112].

Mean Reciprocal Rank (MRR) evaluates ranking quality by measuring how early the first relevant document appears in the ranked list:

$$\mathrm{M}\mathrm{R}\mathrm{R}={\displaystyle \frac{1}{\left|\mathcal{Q}\right|}} \sum _{i=1}^{\left|\mathcal{Q}\right|}{\displaystyle \frac{1}{{rank}_i}}$$

where $\mathcal{Q}$ is the set of evaluated queries, $\left|\mathcal{Q}\right|$ denotes its cardinality, and ${rank}_i$ is the rank position of the first retrieved document deemed relevant for query i. If no relevant document is retrieved within the top-K results, the reciprocal rank is defined as zero [113].

HasHits indicates retrieval success as the proportion of queries for which at least one relevant context is retrieved:

$$\mathrm{H}\mathrm{a}\mathrm{s}\mathrm{H}\mathrm{i}\mathrm{t}\mathrm{s}={\displaystyle \frac{1}{\left|\mathcal{Q}\right|}} \sum _{i=1}^{\left|\mathcal{Q}\right|}1\left[\exists d\in {\mathcal{D}}_K^{\left(i\right)}:\mathrm{o}\mathrm{v}\mathrm{e}\mathrm{r}\mathrm{l}\mathrm{a}\mathrm{p}\left(d,{gold}_i\right)\ge \theta \right]$$

where $\mathcal{Q}$ denotes the set of evaluated queries, ${\mathcal{D}}_K^{\left(i\right)}$ is the set of top-K contexts retrieved for query i, θ is the lexical overlap threshold, and $\mathbf{1}\left[\exists d\in {\mathcal{D}}_K^{\left(i\right)}:\mathrm{o}\mathrm{v}\mathrm{e}\mathrm{r}\mathrm{l}\mathrm{a}\mathrm{p}\left(d,{gold}_i\right)\ge \theta \right]$ is the indicator function, which returns 1 if the condition is satisfied, and 0 otherwise [112].

(d) 

Heuristic Quality Metrics

Harmfulness identifies healthcare misinformation with safety risk using deterministic pattern matching. The method applies five domain-specific regular expression patterns: (i) dangerous treatment language, (ii) anti-medical advice (e.g., “stop medication”), (iii) unsubstantiated cure claims, (iv) known harmful substances (bleach/Miracle Mineral Solution (MMS), unregulated chelation), and (v) anti-vaccination content. The metric is conservative. It favours safety over recall.

$$\mathrm{H}\mathrm{a}\mathrm{r}\mathrm{m}\mathrm{f}\mathrm{u}\mathrm{l}\mathrm{n}\mathrm{e}\mathrm{s}\mathrm{s}=\mathrm{m}\mathrm{i}\mathrm{n}\left(1.0, \sum _{i=1}^5{m}_i\times 0.2\right)$$

where $m_i\in \left\{\mathrm{0,1}\right\}$ indicates whether harmful pattern i is matched in the generated response and $i\in \left\{1, \dots ,5\right\}$ corresponds to the predefined set of harmful content patterns. A score of 0.0 indicates no detected harmful content, while a score of 1.0 reflects the presence of multiple high-risk patterns. Lower values are preferable [114].

Coherence metric measures structural organisation and linguistic quality. It combines sentence validity, discourse connectors, and lexical diversity for short, domain-specific outputs.

$$\mathrm{C}\mathrm{o}\mathrm{h}\mathrm{e}\mathrm{r}\mathrm{e}\mathrm{n}\mathrm{c}\mathrm{e}=\mathrm{m}\mathrm{i}\mathrm{n}\left(1.0, S+C+D\right)$$

where S = 0.3 if at least one sentence exceeds 10 characters (and 0 otherwise), C = 0.3 if at least one discourse connector appears (else 0), and

$$D=\left\{\begin{array}{c}0.4, \mathrm{i}\mathrm{f}\left|\mathrm{W}\right|>20\wedge {\displaystyle \frac{\left|\mathrm{U}\right|}{\left|\mathrm{W}\right|}}>0.5\\ 0.2, \mathrm{i}\mathrm{f} \left|\mathrm{W}\right|>10\\ 0, \mathrm{o}\mathrm{t}\mathrm{h}\mathrm{e}\mathrm{r}\mathrm{w}\mathrm{i}\mathrm{s}\mathrm{e}\end{array}\right.$$

with $\left|W\right|$ total number of tokens and $\left|U\right|$ the number of unique tokens. Discourse connectors include examples such as because, therefore, however, and additionally [115].

Noise Robustness measures reliance on retrieved context rather than speculative language. The metric rewards explicit evidence references and penalises uncertainty markers linked to hallucination.

$$Noise Robustness=\mathrm{c}\mathrm{l}\mathrm{a}\mathrm{m}\mathrm{p} \left(0.3+G-H, 0, 1\right)$$

where $G= \mathrm{m}\mathrm{i}\mathrm{n}(0.5, 0.15 \times |grounding\text{\_}phrases|$) and $H=\mathrm{m}\mathrm{i}\mathrm{n}\left(\mathrm{0.5,0.10}\times \left|\mathrm{h}\mathrm{e}\mathrm{d}\mathrm{g}\mathrm{i}\mathrm{n}{\mathrm{g}}_{\mathrm{p}\mathrm{h}\mathrm{r}\mathrm{a}\mathrm{s}\mathrm{e}\mathrm{s}}\right|\right)$. Grounding phrases include expressions such as “according to”, “based on”, “as mentioned”, and “the context shows”, whereas hedging phrases include expressions such as “I think”, “probably”, “might be”, “could be”, and “generally speaking”. Higher scores indicate evidence-based, context-anchored responses, whereas lower scores suggest speculative or weakly grounded output [116].

The evaluation judge, Meta Llama 3 8B Instruct, operates via local deployment through LM Studio ensuring deterministic reproducibility without reliance on external service dependencies. Embedding generation utilised the mxbai-embed-large-v1 model (text-embedding-mxbai-embed-large-v1). The vector database, Qdrant with HNSW indexing [73], applied a minimum relevance threshold (min_score = 0.3) for context filtering, retaining the top-3 semantically similar chunks per query. This configuration prioritises precision over recall in context selection to minimise hallucination risk while maintaining response groundedness.

4. Results

The empirical evaluation encompasses 250 question–answer pairs evaluated using the complete RAG pipeline with all privacy-preserving components enabled.

Table 4. Aggregate evaluation metrics by dataset.

Metric	DSM-5 QA (n = 100)	Caregiver Notes (n = 150)	Description
Answer Relevancy	0.767	0.750	Query–response alignment
Answer Similarity	0.757	0.730	Embedding cosine similarity
Context Precision	0.599	0.631	Position-weighted relevance
Context Relevancy	0.862	0.858	Query–context alignment
Coherence	0.888	0.927	Logical structure
Harmfulness	0.000	0.000	Safety violation rate
Recall@K	0.400	0.742	Relevant document retrieval
MRR	0.195	0.546	Mean reciprocal rank
Precision@K	0.070	0.241	Retrieval precision
Faithfulness	0.020	0.178	NLI-verified claim support

presents aggregate evaluation metrics stratified by dataset, enabling a comparative analysis between clinical terminology (DSM-5) and Caregiver Observation Notes.

The results demonstrate stable answer quality across both corpora. Answer relevancy scores reach 0.767 for the DSM-5 dataset and 0.750 for the Caregiver Notes dataset, indicating that system responses address user queries regardless of linguistic register. Coherence scores of 0.888 and 0.927 confirm that the generated outputs remain logically structured and highly readable. A zero-harmfulness score across all 250 queries validates the effectiveness of the DLP mechanism and orchestration-level safety controls.

Retrieval performance differs across domains. The Caregiver Notes dataset achieves a higher Recall@K value of 0.742, compared to 0.400 for DSM-5 dataset. This disparity suggests that the embedding and retrieval pipeline captures semantic relationships more effectively in naturalistic observational language than in formal clinical terminology. These findings have direct implications for KB design and domain-specific tuning. Context precision and context relevancy values range from 0.599 to 0.631 and from 0.858 to 0.862, respectively, confirming strong topical alignment between queries and retrieved context, while the moderate precision values indicate remaining opportunities for retrieval optimisation.

Faithfulness scores are low, with values of 0.020 for the DSM-5 dataset and 0.178 for the Caregiver Notes. These results reflect the strict NLI-based verification applied by Llama 3 8B(meta-llama-3-8b-instruct), which requires near verbatim alignment between claims and context. Higher Recall@K values confirm that relevant information is successfully retrieved. Lower faithfulness scores arise from paraphrasing and synthesis during generation. The behaviour reduces NLI-based faithfulness but supports improved readability and clinical usability.

Table 5. Aggregate Evaluation Metrics by DSM-5 Category.

Category	n	Answer Relevancy	Recall@K
Medical/Therapeutic	47	0.782	0.442
Communication	13	0.750	0.475
Behavioural	13	0.827	0.367
Sensory Processing	8	0.781	0.307
Social Interaction	7	0.679	0.281
Therapy Modalities	6	0.750	0.461
Diagnostic Criteria	6	0.708	0.346

presents performance disaggregated by thematic category within the DSM-5 dataset, revealing systematic variation in retrieval and generation efficacy across clinical domains.

Medical-domain queries (n = 47) achieve strong answer relevancy (0.782) and moderate recall (0.442), reflecting the concentration of therapeutic intervention content within the KB. Behavioural observation queries exhibit the highest answer relevancy (0.827), suggesting effective semantic alignment between behavioural terminology and the indexed content. Communication-related queries achieve the highest recall (0.475), whereas social interaction queries exhibit the lowest performance across both metrics (relevancy: 0.679, recall: 0.281), suggesting a potential gap in KB coverage for social development related content.

Table 6. The metadata filter validation.

Test Category	Test Cases	Pass Rate	Validation Scope
Single Value Filter	3	100%	child_id, category, source_type field matching
OR Condition	3	100%	Multiple value matching per field
Combined Filters	3	100%	AND logic across multiple fields
Owner Restriction	2	100%	caregiver_id isolation + combined
Edge Cases	4	100%	Empty results, malformed filters, null values
Use Case	5	100%	Real-world caregiver/specialist scenarios
Category Test	5	100%	Per-category filtering (transitions, communication, sensory, behavior, daily_living)
Performance	2	100%	Multiple OR values, complex combined filters
Collection	3	100%	Cross-collection filtering (global_knowledge, supporter)
Total	30	100%	Full access control coverage

summarises the metadata filter validation results across 30 test cases designed to verify the integrity of privacy-preserving access controls.

All metadata filter tests achieved a 100% pass rate. These results confirm the correct implementation of child_id filtering, caregiver_id restrictions, OR condition queries, combined filters, and owner-based access control rules. Edge case tests confirm correct handling of empty result sets, malformed filter specifications, and boundary conditions.

Limitations

Scope and research stage. As a research artefact, the limitations align with the MVP stage. The study prioritises validation of the core Multi-Agent System architecture and its security and privacy controls, rather than production level optimisation. The contribution encompasses both the conceptual design of the proposed architecture and its quantitative evaluation on 250 test queries using a comprehensive set of 14 metrics adapted from the RAGAs framework.

Evaluation setup and performance constraints. The evaluation focuses on response quality, semantic correctness, and groundedness, measured using metrics adapted from the RAGAs framework. Response latency ranges between 48 and 74 s per query and has not been optimised. The reported values correspond to evaluation time execution, including retrieval, scoring, and LLM-as-a-Judge assessment, rather than end user operational latency.

Methodological limitations of evaluation metrics. Several methodological considerations warrant acknowledgment. First, the use of Llama 3 8B as the evaluation judge, rather than GPT-4 as employed in the original RAGAs framework validation [109], may affect metric calibration. The 8-billion parameter model exhibits more conservative scoring behaviour, particularly for faithfulness assessment, where it applies stricter criteria for claim-context entailment than larger models. This methodological choice prioritises reproducibility and local deployment capability over alignment with GPT-4-based benchmark scores reported in the RAGAs literature [117].

Dataset realism and generalisability are limited by the use of synthetic data. The Caregiver Notes dataset was generated synthetically to reproduce linguistic patterns found in caregiver communication. Synthetic data were used to support PbD and to avoid processing real caregiver records containing personal or health data. The approach enables controlled evaluation under ethical constraints. The dataset does not cover the full variability of caregiver documentation across populations, languages, and cultural contexts. Consequently, generalisation of longitudinal clinical deployment requires further validation.

Domain-specific retrieval limitations. The performance gap between clinical terminology in the DSM-5 dataset and observational caregiver language suggests that embedding models trained on general purpose corpora are less effective for specialised medical vocabulary.

Architectural and security trade-offs. This work follows a DSR approach and presents a designed artefact grounded in established architectural patterns and security principles. The architecture mitigates session hijacking risk within the MCP [118] through frequent token rotation, short-lived sessions, and mutual TLS, which reduce exposure to man-in-the-middle attacks. The design prioritises security, auditability, and legal compliance, resulting in trade-offs with operational simplicity and dynamic flexibility. A deterministic orchestration model was selected instead of an adaptive one to support trust, compliance auditing, and legal accountability. This approach aligns with GDPR and EU AI Act requirements and provides a predictable operational model. The use of a hybrid message bus increases operational complexity but supports performance, durability, and privacy requirements. Service mesh integration introduces additional latency from sidecar proxies, which the design mitigates through gradual adoption.

5. Discussion

The proposed architecture provides an appropriate foundation for an AI-assisted system designed to support autism caregivers:

-

Alignment with stakeholder structure: Caregivers, autistic individuals, and clinicians correspond to distinct roles with different rights and obligations. MASs allow these roles to be mapped to agents and organisational structures, making consent flows explicit rather than implicit.

-

Handling distributed, heterogeneous data: Information about an autistic individual’s routines, behaviours, and interventions is distributed across home devices, clinical records, and educational settings. MASs are designed to operate over distributed environments and can coordinate access through dedicated data access and consent agents.

-

Embedding PbD controls: Privacy and security responsibilities can be assigned to specific agents (e.g., Consent Agent, Security/DLP Agent, Audit Agent), instantiated as first-class entities in the system rather than cross-cutting concerns spread across codebases. This supports data minimisation, purpose limitation, and accountability as required by privacy regulations. The token model described in our scenario applies purpose limitation and data minimisation. Admin approval initiates a UUID token recorded as active or revoked. The dual storage model keeps original text for the caregiver and anonymised text with pii_spans_json for controlled reconstruction. A revoked token blocks reconstruction and returns the anonymised note, enforcing fail-closed behaviour. The DLP engine applies regex, NER, and a context layer that loads child and caregiver names from SQLite. Deterministic salted SHA 256 placeholders keep stable references while reducing re-identification risk. Separate Qdrant collections are maintained for each caregiver–child pair to prevent cross-user leakage. A global knowledge collection provides supplementary specialised information. The Chat Agent fuses both sources to generate guidance tied to child observation records without exposing personal data.

-

Integration with AI components: MASs naturally structure the orchestration of KB, retrieval components, and language models. Within a PbD-compliant workflow, for example, a retrieval agent may interact with a knowledge base of vetted autism resources, while a generation agent produces responses only after consent and security/DLP agents have authorised the use of relevant context. MAS theory provides both conceptual tools (agents, roles, norms, organisations, interaction protocols) and practical engineering guidance (modularity, separation of concerns, explicit coordination) that underpin our architectural choice to design an AI-assisted autism support system as a PbD MAS rather than as a monolithic application or a simple microservices collection.

By embedding principles of privacy, accountability, and ethics directly into the system’s design, the proposed solution operationalises digital trust—an important prerequisite for the sustainable adoption of technology within vulnerable communities.

The modular and interoperable design promotes economic sustainability through component reuse, scalability, and optimisation of operational costs.

The research directly addresses RQ1 and RQ2 through iterative design–build–evaluate cycles. For RQ1, the process operationalises PbD principles into concrete system components—agent roles, communication patterns, and privacy enforcement mechanisms—and assesses their performance and compliance.

For RQ2, the evaluation extends to governance, sustainability, and trustworthiness aspects by comparing the proposed architecture with existing federated and centralised frameworks. The artefact is validated through technical metrics (retrieval accuracy, privacy detection, latency) and analytical methods (LINDDUN threat modelling, compliance mapping, and validity threat assessment).

The findings presented in this paper could provide actionable guidance for developers, system architects, and policymakers engaged in the design of AI-driven digital health solutions.

6. Conclusions and Future Work

The research employs a Design Science Research methodology to develop and evaluate a multi-agent architecture that integrates privacy enforcement, governance, and Large Language Model reasoning within a single, context-aware framework. Through this approach, we provide an integrated perspective on sustainable digital transformation in healthcare.

The proposed design addresses RQ1 and RQ2 by integrating PbD principles into a modular multi-agent architecture and laying the foundation for scalable, sustainability-oriented AI solutions in healthcare.

The primary contributions are threefold:

-

First, the architecture demonstrates that privacy enforcement can be implemented as first-class agents rather than cross-cutting concerns. The Consent Agent, Security/DLP Agent, and Audit Agent operate as autonomous services with clearly defined responsibilities, enabling independent verification and modular evolution. This separation of concerns aligns with both software engineering best practices and the accountability requirements of GDPR Article 5(2).

-

Second, the token-based access control mechanism provides a practical model for implementing purpose limitation and temporal access constraints. The dual storage approach—retaining original text for data subjects while exposing only anonymised versions to authorised processors—demonstrates that data minimisation need not compromise clinical utility when combined with controlled reconstruction capabilities.

-

Third, the hybrid RAG architecture shows that privacy-preserving AI can deliver contextually relevant responses by fusing personal observations with curated knowledge bases. The fail-closed design ensures that system failures result in reduced functionality (KB-only responses) rather than privacy breaches, addressing a critical gap in existing assisted technology deployments.

The empirical evaluation, conducted on 250 question–answer pairs spanning clinical knowledge (n = 100) and caregiver observational contexts (n = 150), confirms architectural feasibility and demonstrates the viability of privacy-preserving RAG deployment on consumer-grade hardware. PII detection achieves robust accuracy through a multi-layer approach combining Microsoft Presidio for Named Entity Recognition, spaCy for contextual entity extraction, and deterministic regex patterns for structured identifiers. RAG-grounded generation achieved answer relevancy scores of 0.767 (clinical domain) and 0.750 (observational domain), with coherence metrics of 0.888 and 0.927, respectively, indicating that the generation pipeline produces contextually appropriate, logically structured responses. The zero-harmfulness detection rate across all 250 evaluation queries validates the effectiveness of embedded safety mechanisms. Metadata filter validation achieved 100% pass rate across 30 test cases, confirming the integrity of privacy-preserving access controls. The differential retrieval performance between clinical (Recall@K = 0.400) and observational (Recall@K = 0.742) corpora suggests opportunities for domain-specific embedding optimisation in future iterations. These findings establish a foundation for subsequent clinical validation studies and inform the roadmap for production deployment in regulated healthcare environments.

Future work will focus on large-scale deployment, extended technical evaluation, and model refinement. Planned steps include the following:

-

Retrieval and faithfulness improvements. Future iterations will address the current faithfulness and retrieval limitations by investigating optimised chunking strategies, prompt refinement, domain-specific fine-tuning, and LLMs to improve response grounding and accuracy.

-

Latency optimisation. Reduce response time from the current 48–74 s through model quantization, caching strategies, and optimised agent orchestration for real-time interaction scenarios.

-

Longitudinal evaluation. Conduct extended studies to measure reliability, policy drift, and caregiver outcomes.

-

Clinical validation. Deploy the system in controlled settings with caregivers and therapists to assess usability, trust, and acceptance.

-

KB expansion. Extend beyond the current DSM-5 dataset (57 chunks) to include additional clinical guidelines, therapy protocols, and regional autism support resources.

-

Domain transfer. Investigate the transferability of the proposed architecture to other application domains under domain-specific personalisation and privacy constraints.

-

Federated learning integration. Add the FL components described in the design to allow model personalisation without centralising sensitive data.

-

IoT integration. Integrate consent-governed IoT data sources with edge processing and/or pseudonymisation to preserve privacy and accountability.

-

Multi-language support. Extend XAI explanations to support users across different languages, building on the existing template infrastructure.