System for user-triggered secure information processing with federated embeddings, private ai models, and blockchain

Abstract

The present invention discloses a system and method for secure information processing that guarantees data privacy, security, and auditability throughout the AI lifecycle. The system empowers the user to classify input data as "public" or "private," which dictates its routing into one of two segregated processing pathways. The public pathway handles non-sensitive information using external AI models, while the private pathway processes sensitive data in a secure, isolated environment. A novel federated embedding capability safely synthesizes insights from both pathways, enhancing the overall quality of the output through their combination, without exposing raw private data. Underpinning the architecture is a pervasive blockchain layer that provides an immutable, cryptographically verifiable record of every action, enforcing data handling policies and ensuring provable security and compliance for regulated industries.

Description

System For User-Triggered Secure Information Processing With Federated Embeddings, Private Ai Models, And Blockchain

[0001] The present invention relates generally to the field of information security and data privacy in artificial intelligence (AI) systems. More particularly, this invention pertains to a system and method for ensuring end-to-end data privacy and secure processing of sensitive information by uniquely combining user-triggered data classification, a dual-pathway Al processing architecture with public and private Al models, the generation of privacy-preserving federated embeddings, and a pervasive blockchain-based authentication and audit layer. The invention is especially relevant to industries handling highly confidential, proprietary, or regulated data - such as healthcare, life sciences, finance, legal, and defense - where secure, verifiable, and user-controlled Al data processing is critically required to meet both operational needs and strict regulatory requirements.

[0002] Recent advancements in large-scale artificial intelligence, particularly in the form of large language models (LLMs) and other generative Al models, have revolutionized data analysis, content generation, and decision-making across virtually every industry. These models, trained on massive corpora of text and other data, exhibit an extraordinary capacity to understand context, summarize information, and produce human-like text, yielding unprecedented efficiencies and capabilities. However, the very power of these systems introduces significant challenges related to data privacy, security, and confidentiality. In conventional Al system architectures, user data is often ingested and processed in a monolithic or uniform manner, with end-users having little transparency or control over how or where their data is handled. This opacity creates substantial privacy risks.

[0003] One major privacy concern arises from the tendency of LLMs to memorize and inadvertently regurgitate portions of their training data. Studies in the security and Al research communities have demonstrated that such models can emit verbatim extracts of sensitive or proprietary training data if that data was seen during training. For example, researchers have shown that an adversary can exploit a publicly accessible LLM to extract unique snippets from its training dataset, including personal identifiers, confidential text passages, or proprietary code sequences. In enterprise and regulated environments where datasets may contain personally identifiable information (PII), protected health information (PHI), trade secrets, or other confidential material, this memorization effect poses a serious leakage risk. A fine-tuned model might inadvertently include parts of a private document in its output to another user. The consequences of such a data breach range from severe regulatory penalties under laws like the General Data Protection Regulation (GDPR) and the Health Insurance Portability and Accountability Act (HIPAA) to irreparable harm to an organization's reputation and competitive position.

[0004] Furthermore, privacy risks extend beyond raw text data to the intermediate representations used within Al pipelines, most notably vector embeddings. Vector embeddings are high-dimensional numerical vectors that capture the semantic content of data (e.g., representing words, sentences, or images). While embeddings are generally not human-readable, recent research shows they are not inherently secure. It is possible to partially or fully reconstruct the original input data from its embeddings using sophisticated inversion attacks. For instance, in the context of text, an attacker with access to a model's embeddings can employ “embedding inversion” techniques to recover significant parts of the original text. A study demonstrated that an adversary could reconstruct about 92% of a 32-token text from its embedding and even recover personally identifiable details from embeddings of clinical notes (Huang et al. 2024, arXiv:2406.10280). Similarly, another study described an information-theoretic approach to infer original inputs from learned representations (Song et al., 2020, arXiv:2004.00053), underscoring that embeddings of sensitive data, if exposed, can leak private information. This vulnerability means that even if raw data is kept confidential, storing or sharing its embeddings without protection can create a backdoor for privacy breaches, a risk that many conventional data anonymization or encryption strategies fail to address.

[0005] In response to these challenges, the field of privacy-preserving machine learning (PPML) has introduced several techniques to safeguard data during model training and inference. One prominent approach is Federated Learning (FL), a decentralized training paradigm where a model is collaboratively trained across multiple devices or servers holding local data, without aggregating the raw data at a central location. Instead of raw data, only model updates or gradients are shared and then aggregated to form a global model. FL improves privacy by keeping personal or sensitive data on device (e.g., on a user's smartphone or an organization's local server). This paradigm has been successfully applied in scenarios like predictive text input on mobile phones and health analytics, reducing the attack surface for data exposure. However, even FL is not foolproof: the exchanged model updates can themselves leak information about the underlying data. Researchers have shown that an adversary can sometimes reconstruct or infer details of training examples from gradients or model parameters shared during federated learning. Thus, without additional protection, FL may still be vulnerable to information leakage through model updates. Techniques like Secure Aggregation (where updates are encrypted and only decrypted in aggregate) are often employed to mitigate this, but they add complexity and computational overhead.

[0006] Another key PPML technique is Differential Privacy (DP), which provides a formal framework for quantifying and limiting privacy leakage. A differentially private algorithm introduces carefully calibrated noise into computations or query responses such that the presence or absence of any single individual's data in the dataset has a statistically negligible effect on the output. In practical terms, this means one cannot confidently infer whether a particular person's data was used, thereby protecting individuals' privacy. DP can be applied to model training (e.g., by adding noise to gradients or limiting their influence through mechanisms like gradient clipping and perturbation, as in the DP-SGD algorithm) or to the outputs of queries. The strength of the privacy guarantee is parameterized by values such as ε (epsilon), where a smaller ε indicates stronger privacy (and typically more noise added). Major tech companies have implemented DP for tasks like telemetry collection and language model training on user data, albeit often with relatively large ε that provide modest privacy. A known downside of differential privacy is the trade-off between privacy and accuracy: adding noise can degrade model utility, especially if rigorous privacy (small ε) is required. Hence, deploying DP in practice involves balancing privacy needs with acceptable model performance, and carefully managing the “privacy budget” consumed by repeated queries or training epochs.

[0007] Other advanced methods have been explored to protect data during Al processing. Homomorphic Encryption (HE) allows computations to be performed directly on encrypted data without decrypting it, so that the computing party never sees the plaintext data. A fully homomorphic encryption scheme (FHE) can theoretically enable an Al service to operate on sensitive inputs (e.g., computing an inference) while the data remains encrypted; the result, when decrypted by the data owner, is the same as if computed in plaintext. While groundbreaking, FHE is extremely computationally intensive; performing deep learning inference or training under FHE can be orders of magnitude slower, making it impractical for large models or real-time use with current hardware in many cases. Secure Multi-Party Computation (SMPC), on the other hand, enables multiple parties to jointly compute a function over their inputs (such as training a model on combined private datasets) without revealing their own inputs to others. SMPC protocols (e.g., Yao's Garbled Circuits for two-party computation, or general n-party protocols based on secret sharing) can be used to split data and computation so that no single party learns the full information. SMPC has been applied in scenarios like private set intersection and federated analytics. However, like HE, it often introduces large communication and computation overheads, particularly as the number of participants or the complexity of the model grows. A related approach involves hardware-based trusted execution environments (TEEs), such as Intel SGX, where code and data run inside a secure enclave protected from the host system. TEEs can confine sensitive computations, but come with limitations in memory and trust (one must trust the hardware vendor).

[0008] Beyond confidentiality of data, ensuring transparency and accountability in Al processes has emerged as an important consideration, especially for compliance and audit purposes. In this regard, blockchain technology has attracted interest as a tool for creating immutable audit logs and enforcing data provenance. A blockchain is a distributed ledger maintained by a network of nodes, where each recorded transaction is cryptographically linked to the previous one. Once recorded, entries are extremely difficult to alter without detection. By leveraging a permissioned blockchain (i.e., one where only authorized parties can participate in the consensus), organizations can create a tamper-proof log of events in an Al system. For example, every access to a sensitive dataset, every training session, and every inference query could be logged as a blockchain transaction. Prior works have proposed using blockchains to enhance data integrity and provenance tracking in supply chains, healthcare record management, and IoT networks. In the Al context, Hyperledger Fabric (a popular permissioned blockchain framework) has been identified as suitable for enterprise audit trails, providing cryptographic verification of transactions (e.g., logging each time training data is used or model parameters are updated). The advantage is that such a ledger is append-only and shared, making it very hard for a malicious insider to cover their tracks or for an external attacker to falsify records without collusion. Of course, blockchains introduce their own overhead (in terms of transaction processing and throughput) and must be carefully designed so as not to expose sensitive data in the ledger itself (often the ledger will store hashes or references, not the data content). Nonetheless, the concept of integrating a blockchain as an audit layer offers a promising route to satisfy stringent compliance requirements by providing an independently verifiable history of all relevant operations.

[0009] While the challenges outlined above are known, existing solutions in the art address only parts of the problem. U.S. Patent US12316753B1 describes a secure multi-agent system enabling privacy-preserving distributed computation within isolated execution environments, with blockchain integration for secure auditing and verification. However, this system does not teach an explicit, user-driven classification step at the point of data ingestion, nor does it describe federated embeddings combining public and proprietary data insights dynamically and securely.

[0010] U.S. Patent US12316655B1 describes a cyber resilience agentic mesh composed of autonomous agents handling tasks with explicit memory segmentation and security policies defined by users. Despite its focus on privacy through isolation, it lacks real-time user-triggered data classification for dynamically segregating proprietary and public data pathways within Al pipelines, as well as mechanisms for federated embedding generation.

[0011] U.S. Patent US12335379B1 introduces a privacy-preserving transformer model featuring encrypted dimensionality reduction and secure embedding handling within transformer architectures. While offering protection at the embedding level, this approach does not include user-driven proactive classification, strict segregation of public and proprietary processing pathways, nor the integration of blockchain authentication to secure proprietary data access and logging.

[0012] U.S. Patent US12155781B1 presents a decentralized data management system employing blockchain technology for identity tracking, data management, and dynamic verification of data transactions. Although emphasizing secure decentralized handling, it does not explicitly address dual-pathway Al model processing segregated by data sensitivity, user-driven privacy toggling, or real-time federated embeddings combining public and proprietary insights.

[0013] Chinese Patent CN118520505B describes a blockchain-based approach for traceability and validation in generative Al outputs, primarily aimed at content evaluation and authenticity checks. However, it lacks the concept of a user-driven privacy classification at data input, dynamic routing into dual segregated execution paths, and federated embedding mechanisms securely integrating public and proprietary data insights.

[0014] Chinese Patent CN118413359B outlines a comprehensive network information security system utilizing dynamic real-time classification and secure routing of network data via network slicing and encryption methods. Nevertheless, this invention does not extend to user-driven explicit classification within Al data ingestion processes, federated embeddings combining proprietary and public contexts, nor comprehensive blockchain auditing spanning the entire Al query lifecycle.

[0015] Chinese Patent CN118312626B describes data management strategies employing federated learning distributed across multiple data nodes to enable secure and collaborative data analysis. Although relevant to the concept of federated embeddings, it lacks explicit user-driven data sensitivity tagging, dual isolated pathways for data handling, and pervasive blockchain-based authentication and auditing for end-to-end secure processing.

[0016] Chinese Patent CN117725630B covers dynamic security protection methods and metadata-based encryption for secure routing and controlled data access. Yet, it does not include mechanisms for real-time user input-driven data classification into public and proprietary pathways, federated embeddings leveraging combined insights, or blockchain-based secure access authentication of proprietary resources.

[0017] U.S. Patent US12032556B2 discloses a distributed machine learning architecture integrating hybrid data normalization and proof layers, separating raw data channels from metadata channels in secure environments. This invention does not describe user-driven dynamic data classification for initiating separate Al processing streams based on data sensitivity, nor does it include blockchain-led secure authentication for proprietary data sources or federated embedding strategies.

[0018] The present invention discloses a comprehensive system and a method for secure information processing that guarantees data privacy, security, and auditability throughout the entire artificial intelligence (AI) lifecycle. It provides a novel technical framework that fundamentally redesigns how AI systems interact with sensitive data, shifting control from the system to the user.

[0019] At its core, the invention empowers the end-user to be the ultimate arbiter of their data’s privacy. When a user submits information, they are required to make an explicit and clear classification, designating the data as either “public” or “private.” This initial user-driven decision dictates the data’s entire journey through the system. Based on this classification, the system automatically routes the information into one of two completely distinct and segregated processing pathways, eliminating the risk of accidental commingling or data leakage.

[0020] The public pathway is designed to handle non-sensitive information, where it is permissible to leverage the full power of external or cloud-based AI models and public knowledge bases. Conversely, the private pathway is a highly secure, isolated computational environment, such as an on-premises server or a dedicated secure cloud instance. Within this private sanctuary, sensitive data is processed by private AI models that are sandboxed from external networks. All private information and any representations derived from it, such as vector embeddings, remain confined within this trusted boundary at all times.

[0021] A unique capability of the invention is its ability to safely synthesize insights from both public and private sources. To answer complex queries that require both types of information, the system brings public insights into the secure private environment for analysis. This allows the AI to generate a richer, more contextually aware output by leveraging both datasets, but critically, ensures that the raw private data is never exposed. Furthermore, the user retains granular control over the final output, with the ability to specify which portions of a generated document or response can be derived from private data, public data, or a combination of both.

[0022] Underpinning this entire architecture is a pervasive blockchain layer that provides an immutable and cryptographically verifiable record of every action taken. This layer serves as more than a simple audit log; it functions as an active security fabric that programmatically enforces data handling policies and provides cryptographic authentication for access to proprietary data sources. This ensures that the system’s security is not merely a claim but a provable reality, building trust and enabling the confident application of AI in highly regulated industries such as healthcare, finance, and legal services.

[0023] The use of large-scale AI models in industries handling sensitive data presents a significant technical problem related to data privacy, security, and control. Conventional AI architectures lack transparency and user control, creating substantial risks. A primary technical challenge is the inherent tendency of AI models to memorize and inadvertently regurgitate sensitive portions of their training data, such as Personally Identifiable Information (PII) or trade secrets, posing a severe data leakage risk. Another critical challenge is the vulnerability of intermediate data representations, such as vector embeddings, which can be reverse-engineered to reconstruct original sensitive information, creating a backdoor for privacy breaches even when the raw data is kept confidential.

[0024] Existing solutions in the art are insufficient to address this multifaceted problem comprehensively. Privacy-preserving techniques like Federated Learning (FL) can still leak information through model updates, while Differential Privacy (DP) often forces an undesirable trade-off between the strength of privacy and the utility of the AI model. More advanced methods like Homomorphic Encryption (HE) and Secure Multi-Party Computation (SMPC) are typically too computationally intensive and suffer from overhead that makes them impractical for large-scale, real-time AI applications. Furthermore, while blockchain technology offers a path to auditable records, its integration into AI workflows without creating performance bottlenecks or new data exposure risks is itself a challenge.

[0025] Therefore, a significant gap exists in the art for a single, holistic, and user-centric security framework. There is no known system that integrates (a) explicit, user-driven data classification at the point of ingestion, (b) a strictly segregated dual-pathway processing architecture to prevent data commingling, (c) a secure mechanism for federating insights from both private and public data sources without exposing private data, and (d) a pervasive, immutable blockchain-backed audit trail that provides both verifiable proof of compliance and active policy enforcement. The technical problem is the absence of a full-stack solution that provides architectural guarantees for data privacy, controlled by the user, from input through processing to output.

[0026] The present invention solves the aforementioned technical problem by providing a comprehensive system and method architected around user-driven control and verifiable data segregation. The solution is instantiated through a set of interacting modules that systematically manage data from ingestion to output.

[0027] The core of the solution begins at the User Input Module. This module fundamentally shifts control to the user by requiring an explicit and mandatory classification of all incoming data as either "public" or "private" before any processing occurs. This initial, user-decreed classification is immutably recorded as a transaction on a blockchain layer, creating an auditable and non-repudiable record of the data's intended privacy status.

[0028] Based solely on this classification label, the Data Processing & Routing Module acts as a deterministic gatekeeper. It directs the data into one of two architecturally segregated pathways. Data labeled "private" is routed to the Private AI Pathway, a highly secure and isolated computing environment (e.g., an on-premises server or a locked-down virtual private cloud with no external network access). Within this sanctuary, data is processed by private AI models that are sandboxed and confined. All derived representations, including sensitive vector embeddings, are stored in a private vector database and never leave this secure environment. Conversely, data labeled "public" is routed to the Public AI Pathway, which can leverage the full power of external or cloud-based AI models and public knowledge bases, as data sensitivity is not a concern. This strict, policy-enforced segregation provides a fundamental architectural guarantee against the commingling of sensitive and non-sensitive data, thereby preventing a primary cause of data leakage.

[0029] To enable the use of both public and private knowledge without compromising security, the system employs a Federated Embedding Module. This module operates exclusively within the secure environment of the Private AI Pathway. When a query requires combined insights, this module retrieves results or embeddings from the Private Pathway and, in parallel, securely ingests publicly derived embeddings or insights from the Public AI Pathway. It then merges these insights within the secure boundary to produce a richer, more contextually aware output. Crucially, the raw private data and its direct embeddings are never exposed to the public pathway or any external service.

[0030] The entire system is enveloped by a Pervasive Blockchain Authentication Layer. This layer functions as more than a passive audit log; it is an active security enforcement mechanism. Using smart contracts, it verifies permissions and enforces data handling policies in real-time, for example, by programmatically preventing any transaction that would attempt to send private-labeled data to the Public AI Pathway. It records every critical event—user classification, data routing, model invocation, and output generation—as a cryptographically signed, immutable transaction, providing a tamper-resistant and independently verifiable trail for compliance, security audits, and forensic analysis.

[0031] The present invention provides a multitude of advantageous effects that overcome the limitations of the prior art, delivering a framework for trusted and secure AI. A primary advantage is the establishment of Complete User Control and Data Privacy by Design. Unlike conventional systems where privacy settings are an afterthought or opaque to the user, this invention empowers the user to be the ultimate arbiter of their data's privacy. The mandatory classification step at the point of ingestion ensures that control is proactive and user-driven, not system-assumed. This fundamentally alters the user-system relationship to one of explicit trust and control.

[0032] Another significant advantage is the Architectural Elimination of Data Leakage and Cross-Contamination Risk. The strict, dual-pathway processing architecture provides a robust, verifiable guarantee that sensitive private data will never accidentally commingle with public data or be processed by an insecure external model. This hard segregation solves the critical problems of model memorization and inadvertent data exposure that plague monolithic AI systems.

[0033] The invention provides the advantageous effect of Enhanced AI Utility without Sacrificing Confidentiality. The novel Federated Embedding Module creates a secure bridge that allows the system to generate richer, more accurate, and more contextually aware AI outputs by leveraging insights from both proprietary data and vast public knowledge bases. It achieves this without ever moving the sensitive raw data or its direct embeddings outside the secure private environment, thereby solving the classic trade-off between data utility and data privacy.

[0034] Furthermore, the system delivers Provable Security and Verifiable Compliance. Security is not merely a policy claim but a provable reality. The Pervasive Blockchain Authentication Layer provides a tamper-resistant, immutable audit trail of every single critical action taken on a piece of data. This allows an organization or an external auditor to independently verify that all data was handled according to its specified privacy classification and that no policies were violated. This is exceptionally valuable for regulated industries like healthcare (HIPAA) and finance (GDPR), as it provides the concrete evidence needed to demonstrate compliance.

[0035] Finally, the invention offers Granular Output Provenance and Superior Forensic Capabilities. The system tags all generated output with its data lineage, indicating whether it was derived from public, private, or dual sources. This allows for fine-grained control over the dissemination of final results. In the event of a suspected breach, the detailed blockchain logs enable a precise forensic analysis to trace the lifecycle of the compromised data, identifying exactly what was accessed, by whom, and what output it influenced. This provides a level of accountability and traceability that is absent in conventional AI logging systems.Fig.1

[0036] illustrates the high-level system architecture of the main modules and their high-level interactions and data flows, as per a non-limiting embodiment of the invention.Fig.2

[0037] presents a workflow diagram for user-triggered secure information processing for creating a regulatory submission as per a non-limiting embodiment of the invention.Fig.3

[0038] depicts a network and hardware architecture for secure information processing in an Al environment, as per a non-limiting embodiment of the invention.Fig.4A-4E

[0039] These figures illustrate graphical user interface (GUI) screens for user-driven data classification and granular control over output provenance within an exemplary regulatory submission workflow, as per a non-limiting embodiment of the invention.

[0040] illustrates the initial user interface for explicit classification of data as 'public' or 'private (proprietary)' during file upload.

[0041] displays the file selection dialog, demonstrating file organization for upload into the public or proprietary data sections.

[0042] depicts the upload interface with multiple files populated into their respective 'Public Data' and 'Proprietary Data' sections.

[0043] illustrates the user interface for granular control over output provenance, allowing specification of data source (Proprietary, Public, or Dual) for individual document sections.

[0044] presents a sample view of an Al-generated document, demonstrating the final output with content drawn according to user-defined provenance settings for a regulatory submission.

[0045] The following is a full description of a preferred embodiment of the invention. The embodiments are described in such a way that the disclosure is clearly communicated. The level of detail provided, on the other hand, is not meant to limit the expected variations of embodiments; rather, it is designed to include all modifications, equivalents, and alternatives that come within the spirit and scope of the current disclosure as defined by the attached claims. Unless the context indicates otherwise, the term "comprise”; and variants such as “comprises”; and “comprising" throughout the specification are to be read in an open, inclusive meaning, that is, “including, but not limited to"; When “embodiment” or “an embodiment” is used in this specification, it signifies that a particular feature, structure, or characteristic described in conjunction with the embodiment is present in at least one embodiment. As a result, the expressions “one embodiment” and “in an embodiment”; that appear throughout this specification do not necessarily refer to the same embodiment. Furthermore, in one or more embodiments, the specific features, structures, or qualities may be combined in any way that is appropriate. Unless the content clearly demands otherwise, the singular terms “a”, “an”, and “the”; include plural referents in this specification and the appended claims. Unless the content explicitly mandates differently, the term “or” is normally used in its broad definition, which includes “and / or”.

[0046] The use of any and all examples, or exemplary language (e.g. “such as") provided with respect to certain embodiments herein is intended merely to better illuminate the invention and does not pose a limitation on the scope of the invention otherwise claimed. No language in the specification should be construed as indicating any non-claimed element essential to the practice of the invention.

[0047] The headings and abstract of the invention provided herein are for convenience only and do not interpret the scope or meaning of the embodiments. All publications herein are incorporated by reference to the same extent as if each individual publication or patent application were specifically and individually indicated to be incorporated by reference. Where a definition or use of a term in an incorporated reference is inconsistent or contrary to the definition of that term provided herein, the definition of that term provided herein applies and the definition of that term in the reference does not apply.

[0048] Groupings of alternative elements or embodiments of the invention disclosed herein are not to be construed as limitations. Each group member can be referred to and claimed individually or in any combination with other members of the group or other elements found herein. One or more members of a group can be included in, or deleted from, a group for reasons of convenience and / or patentability. When any such inclusion or deletion occurs, the specification is herein deemed to contain the group as modified thus fulfilling the written description that follows, and the embodiments described herein, is provided by way of illustration of an example or examples, of particular embodiments of the principles and aspects of the present disclosure. These examples are provided for the purposes of explanation, and not of limitation, of those principles and of the disclosure.

[0049] It should also be appreciated that the present invention can be implemented in numerous ways, including as a system, a method or a device. In this specification, these implementations, or any other form that the invention may take, may be referred to as processes. In general, the order of the steps of the disclosed processes may be altered within the scope of the invention. Various terms as used herein are shown below. To the extent a term used in a claim is not defined below, it should be given the broadest definition persons in the pertinent art have given that term as reflected in printed publications and issued patents at the time of filing.

[0050] Overall Architecture: As shown in, the system (100) is composed of multiple interacting modules arranged in a layered security architecture. At the top, user interactions occur through the User Input Module (110), which interfaces directly with the end-user. Below that, the Data Processing & Routing Module (120) orchestrates the flow into either the Public Al Pathway (130) or the Private Al Pathway (140) based on user input. The Public Al Pathway (130) includes at least one public Al model (e.g., a cloud-based LLM service) and a public vector database for non-sensitive embeddings, whereas the Private Al Pathway (140) includes at least one private Al model (running in a secure environment) and a private vector database for sensitive embeddings. Both pathways feed into the Federated Embedding Module (150) when dual-source analysis is required, and the results are passed to the Secure Output & Storage Module (170) for final output assembly and delivery. Overarching all components is the Pervasive Blockchain Authentication Layer (160), which is depicted as a layer enveloping the modules to indicate that it interacts with each of them, providing authentication, integrity verification, and logging. Arrows in the figure illustrate the flow of data and control: from the user input to routing, then into either private or public processing, and then potentially into the federated module and finally to output. The dotted-line block of the blockchain layer enveloping all other modules signifies that each module both informs the blockchain (by logging events) and is informed / controlled by it (via authentication checks and smart contract rules).

[0051] User Input Module (110): The user input module is the entry point for all data and commands from end-users. It may be implemented as a graphical user interface in a software application, a web-based interface, a command-line tool, or an API endpoint for programmatic access. The primary inventive feature of this module is the mechanism forcing the user to choose a privacy classification for each input. In one embodiment, when a user is about to submit text (such as uploading a document or asking a question), the interface prominently displays options (e.g., a segmented control buttons, toggle switch, radio buttons, or a dropdown menu) labeled “Public” and "Private.” The user must select one of these before the system will accept the input. For example, an upload dialog might have a guidance text labeling the upload control as “PROPRIETARY”. Internally, once the user classifies the data, the module tags the data with metadata indicating its classification and possibly the user's identity and session information. It then encapsulates this in a message or data structure to send to the routing module (120). Immediately upon classification, the module, through integration with blockchain layer (160) creates a log entry on the ledger: e.g., a transaction that reads "User Alice classified Document #1234 as PROPRIETARY on 2025-07-08 10:00:00 UTC” with Alice's user ID and a hash of the document (or some identifier). This log is digitally signed (using Alice's private key or a system key attesting to the event) and forms a permanent record. This not only ensures the decision is recorded (preventing disputes later about whether data was considered private), but also triggers smart contracts that set the context for subsequent handling (the smart contract can now enforce that doc #1234 must only be processed in private mode). In alternative embodiments, the user's classification might be inferred or aided by defaults or Al (for example, the system might auto-suggest “This looks like it contains names, mark as private?"), but the final decision rests with the user to satisfy the object of proactive user control. The user input module also typically handles initial authentication of the user (ensuring the user is logged in or otherwise identified to tie their actions to an identity in the blockchain log). Additionally, it could display to the user a summary of how their data will be handled (e.g., “Note: Private means your data will not leave our secure server.") to promote informed decisions.

[0052] Data Processing & Routing Module (120): The routing module is a logical gatekeeper that receives the input data along with its classification from the User Input Module. Its function is straightforward yet critical: based on the attached classification, it forwards the data to the appropriate Al processing pathway. If the data is labeled “public,” it invokes the Public Al Pathway (130); if “private,” the Private Al Pathway (140). This can be implemented via direct function calls, message passing (like putting a message on a secure queue that the respective pathway's components consume), or service invocation patterns (like calling an API endpoint for the private service vs. a different endpoint for the public service). The separation here is clean—there are ideally separate codebases or at least separate execution contexts for each pathway, and the routing module ensures the data only goes to one. From a security standpoint, this module marks the point-of-no-return separation: once a piece of data is classified as private, this module will never send it to anything in the public domain. To reinforce this, the blockchain smart contracts could contain a rule that flags any transaction where data labeled private is input to a public model. The routing action itself is logged: e.g., "System routed Document #1234 to Private Pathway at time T, per user classification,” thus linking the user's choice to the system's enforcement. The routing module may also attach or transform metadata as needed (for example, if the private pathway expects data in a certain format, the router might prepare it). Importantly, this module enforces a design where new data cannot go to both pathways simultaneously, preventing duplication or mix-ups. In some embodiments, the routing could allow copying public data to both paths (since there's no harm processing public data with private resources if desired, aside from inefficiency), but there is typically no need to do so. Private data unequivocally goes only to the private path. The deterministic nature of the routing module also simplifies auditing—given a data ID and timestamp, one can easily check in the ledger which route was taken.

[0053] Public Al Pathway (130): The public pathway is designed for scalability and integration with external Al capabilities, under the assumption that data here does not require special secrecy. In one embodiment, the Public Al Model might be an API client that sends the input to a third-party LLM service (e.g., OpenAl, Google, or another provider) and receives a completion or analysis. Alternatively, it could be a local model that is nevertheless not restricted from internet access or from using general knowledge (since it only handles public data, contamination is not a concern). The tasks the public model performs can include natural language understanding, question answering using public knowledge, summarization of public content, etc. The pathway likely includes an embedding generation step: for example, when a user provides some public text (like a generic question or a non-sensitive document), the system creates an embedding vector via the public model's embedding endpoint or a related algorithm. That embedding is then stored in the Public Vector Database, which could be a service like Pinecone, Weaviate, or even a simple vector index in memory or on disk. The public vector DB is accessible to the public model and possibly even to external systems (if the architecture allows, though it would typically still be read / write protected internally). Its content might include embeddings not only from the user's current input but from all sorts of public data sources aggregated (like a cache of Wikipedia article embeddings, etc.). The assumption is that everything in this DB is not sensitive, so even if it were compromised, the risk is minimal. Nonetheless, best practices (like encryption at rest, authentication for access) are still applied. Within this pathway, if multiple services are used (e.g., one for embedding, another for answering), they all operate in a context free of sensitive constraints. The public pathway can thus leverage the full power of cloud resources and updated knowledge (like real-time search results) without restriction. A note on design: the public pathway could be entirely skipped for certain queries that are exclusively private, but it's still logically present. For queries labeled public, only this pathway is invoked. For dual queries, both this and the private pathway might be used (with coordination via the federated module). The public pathway's actions are typically less heavily logged on the blockchain than the private side, but still, key operations are recorded. For instance, if the public model retrieves data from an external search, the system might log the search query and maybe the sources (to later justify where any public info came from in an answer). If an embedding is stored, it logs a reference like "Embedding of PublicData ID456 stored at index 789 in PublicDB.” These ensure traceability and also help in debugging or improving the knowledge base (e.g., one can see what public info was used for what question).

[0054] Private Al Pathway (140): This pathway handles sensitive data in a locked-down environment. The Private Al Model could be any Al model suited to the task, such as a transformer-based language model fine-tuned on the organization's data, a domain-specific model (like a medical NLP model for clinical text), or even a traditional ML model depending on use case. The key requirement is that this model is deployed in a manner isolated from untrusted networks: for example, it runs on a server with no internet access, or within an enclave that encrypts memory and only allows certain code to run. All communications to this model come through secure, authenticated channels from inside the system. Data arriving at the private pathway might be first placed into a secure storage (e.g., temporarily in an encrypted file accessible only to the private model's process) or streamed directly to the model. The model processes it – this might involve reading internal knowledge bases, performing analysis, etc. If the task involves generating an embedding (common in retrieval tasks), the model or an associated embedding service computes a vector representation of the input. This Private Embedding is then stored in the Private Vector Database. The private vector DB is likely implemented on encrypted storage, within the same secure network. Access to it is tightly controlled: possibly only the Private Al Model or the Federated Module can query it, and even then, via local calls rather than network requests, to minimize exposure. This database contains sensitive semantic representations, which as discussed, can themselves be abused to glean original data, so they are treated with nearly the same care as raw data. In some embodiments, techniques may be applied to the embeddings to make them safer (like applying a form of dimensionality reduction or adding noise so that perfect inversion is harder), but even then they are not shared outside. The private model can also generate direct outputs (like the answer to a question asked solely on private data). Those outputs are considered sensitive until proven otherwise (the user could explicitly decide to mark a particular result as shareable). Therefore, further use of them would be through the output module where they could be tagged accordingly. The physical deployment of the private pathway could be on separate hardware or just segregated via virtualization / containerization with strict firewall policies. The system could use cloud infrastructure too, but in a single-tenant mode (like a dedicated VPC with no outside connectivity) to approximate on-prem security in a cloud. Another aspect is that the private model could be allowed to use the private vector DB to augment its responses (similar to retrieval-augmented generation but on private data). For instance, if the user asks a question, the private model might perform a vector search in the private DB to fetch relevant internal documents and use them to compose an answer. This is entirely within the private scope and does not involve the public path unless needed. As with all else, every critical operation in this pathway triggers blockchain logging. The invocation of the private model logs which model (if models are versioned or there are multiple-this matters because if later a model is found to have a bug or to be compromised, one can audit which data was processed by it). The storing of an embedding logs the index or a hash of the embedding to link it to the original data's hash (creating a chain of transformation records). Also, any read from the private DB (like to retrieve context for a query) can be logged with references to what was retrieved (maybe not the content itself but an ID or hash). This way, if an answer was generated, one can check exactly which private items influenced it, which is crucial for compliance in some cases (e.g., in finance or healthcare, to show what sources an Al used to make a recommendation).

[0055] Federated Embedding Module (150): This module is invoked when an operation or query requires both private and public data. It acts as a mediator that can safely combine insights. In one embodiment, when a user query arrives that is marked or determined to need dual processing, the system does the following: it passes the query to the Private Pathway to get a private response or embedding (e.g., find what internal data is relevant) and in parallel to the Public Pathway to get a public response or embedding. The Federated Module running in the secure environment then takes the private result and the public result and merges them. For example, if the task is information retrieval, the federated module might take the top N private documents and top M public documents relevant to the query, then rank all N+M together (this ranking could be done using a combined embedding approach-like average of vectors, or a cross-encoder model that looks at query and documents together). The top results regardless of origin can then be used to construct an answer. The key is that the actual merging logic runs where the private data is, so that any public data comes to that environment (which is fine since public data doesn't introduce risk), but private data never leaves it. If the task is more about combining numeric or analytic results (e.g., "internal sales grew X%, industry grew Y%”), the module might extract the number X from a private analysis and Y from a public analysis and then synthesize the comparative statement. It may call a model to generate text that incorporates both X and Y. This could be done by the private model (so that even the text generation happens internally, meaning X is never sent to an outside service) or by a public model if, for instance, X and Y are sufficiently high-level non-sensitive numbers that the user is okay with them being processed externally. The system can allow that nuance: maybe certain aggregate data is deemed non-sensitive by policy, so in those cases it's permissible to use a public service. If so, that would be a rule encoded likely in the blockchain smart contracts or a policy engine (for example: “if data is aggregate and older than 1 year, allow in public"). In absence of such, the default is caution: do everything in private side once private data is involved. The federated embedding can also refer to literally creating a single vector that captures joint info. One method could be concatenating the private and public embeddings into one longer vector (with appropriate weighting), which can then be used for further similarity computations. The resulting federated embedding is then treated as sensitive if it contains private influence. It might be stored temporarily or persistently in a secure part of memory or even in the private vector DB with a special tag that it's a federated artifact. By doing so, the system can even answer similar future queries faster (since the combined insight was cached). Of course, one must ensure that storing such combined results doesn't inadvertently expose private info (here it's stored privately, so it should be okay; but if one ever considered storing it in a public location, that would need analysis of how much private data could be inferred from it). The federated module might also apply additional privacy measures, like differential privacy noise, at this stage, particularly if outputs might leave the private realm. For instance, if the user explicitly requests the final answer be shareable publicly, the system might ensure that any private contributions are either removed or sufficiently obfuscated (perhaps by adding slight inaccuracies or generalizations that fall within an acceptable epsilon of DP). The design of the federated module is thus quite flexible, and it can employ advanced techniques as needed to balance info utility and privacy. The module's actions are logged too: e.g., “Federated combination performed using PrivateEmbedding #abc (hash h1) and PublicEmbedding #xyz (hash h2)” or listing which data items from each side were used. Smart contracts might also enforce here that only certain combinations are allowed (maybe an org could restrict that certain highly sensitive datasets never get combined with public info, even internally).

[0056] Secure Output & Storage Module (170): This module takes care of the endgame: delivering results to the user and storing them if needed, in line with user-specified or policy-specified constraints. When the Al system finishes processing, it will have some result content—this could be an answer to a query, a full report, a set of recommendations, etc. The output module first correlates this with the provenance information. If the user has tagged sections in advance (like in a template for a report), the module knows which section came from which pathway. If the user is simply doing Q&A, the system may classify the answer as private or public depending on sources. For instance, if the answer used any private data, the system might by default mark the whole answer as private (unless it's known that nothing sensitive was actually revealed, which might require semantic analysis or user judgment). The user interface can present the answer and indicate, for example, “This answer contains confidential information from internal sources.” The user can then decide how to handle it (maybe ask for a sanitized version). In a document scenario, the user could request, after generating a fully private version, that the module generate a redacted version for public sharing. The module would then replace or remove the private content, possibly by re-querying the public model to fill those gaps with publicly available equivalents if possible. Secure storage is another aspect: if any outputs (like the internal full report) need to be saved, it should be saved in an encrypted form in a database or file system accessible only to authorized users (likely the same classification as the data inside). The module can annotate the saved file with metadata listing what it contains (no need to embed actual data, but flags like “Contains Private Data from dataset X” so later an access control can check that before serving the file to someone). If the output is to be sent out (like via email or API), similar checks apply: the system should ensure that a “public” output is indeed free of private info. If not, it may block the action or warn the user. Essentially, the secure output module enforces the last line of defense—ensuring that what leaves the system is appropriate. And of course, it logs what is delivered or stored. For example, it might log “Output O (hash hO) delivered to User U at T, containing sections A (from private data) and B (from public data).” If the user then shares that output externally (outside the system), that's beyond the system's control, but at least internally it's recorded what was shared. If a breach happens, one can trace it: e.g., if some secret info leaks, they can see that output O had it and was given to user U, hence the leak likely came from U's copy. This is the forensic value of the audit logs.

[0057] Blockchain Authentication Layer (160): Finally, integrating all of the above is the blockchain layer. It's called “pervasive” because it touches every transaction. In implementation, this could be realized by having each module's software make calls to a blockchain node or client library every time it does something noteworthy, and also by having certain functions gated by blockchain-based permission checks. The blockchain itself could be a private one (like using Hyperledger Fabric or Quorum or a similar enterprise blockchain technology) where nodes are run on the organization's servers. It could also be a consortium chain if multiple stakeholders are involved (e.g., maybe in a multi-organization research scenario, each party runs a node to verify the process). Public blockchains (like Ethereum mainnet) would likely be too open and slow (and putting data there would be insecure), so permissioned is preferred. The ledger would maintain smart contracts (chaincode in Hyperledger terminology) that codify the rules: these rules might include: “Only accept a processing transaction if the data was previously logged as present and classified appropriately”, “Only allow output transactions if all input data they reference has been properly processed according to rules”, etc. Essentially, it's both a log and a policy engine. For authentication, every user might have a blockchain identity (like a public key). The user's classification action is signed by their key (so later, they can't repudiate it). Every service or module might also have keys or be represented by a smart contract identity. Before performing a task, a module might create a proposal on the blockchain which other nodes (or the contract) validate. For instance, when the routing module tries to send data to private model, it could emit a transaction “Attempting to invoke private model with Data #1234 (private)”, and a smart contract could check “Data #1234 is indeed marked private in prior transaction and the caller is authorized to use the private model” then log an approval that in effect signals the private model container to proceed (this could be orchestrated by off-chain triggers as well). While a real-time blocking on blockchain might be slow if not designed carefully, enterprise chains can handle relatively fast transactions (Fabric can do thousands per second). Also, not every minor step needs a separate transaction if grouped logically. The ideal is that an independent auditor can later replay the sequence of blockchain records and convince themselves that at each branch the correct path was followed and no rules were broken. Data integrity logging in particular is worth re-emphasizing: by logging hashes of inputs, outputs, and intermediate embeddings, the system enables audits or even legal evidence. For example, imagine a dispute arises about what data was used to generate a financial recommendation. The company can show on the ledger: hash of dataset, hash of model used, hash of recommendation output. The actual content can be hashed again and matched to confirm no tampering. It might also help detect if an attacker tried to inject data: if an input wasn't logged by the user but somehow a later transaction references an unknown data ID, the system would see an inconsistency. The blockchain thus acts as both a preventive control (via smart contracts enforcing decisions) and a detective control (via logs that expose anomalies). The use of blockchain, as opposed to simple centralized logging, is to achieve tamper-resistance and distributed trust. Even if an attacker compromised the application servers, they couldn't retroactively alter the log to cover their tracks without also breaking the blockchain consensus (which in a well-run network, they shouldn't control the majority of nodes). This mitigates insider threats too-administrators can't quietly reroute data or use it improperly because the blockchain would record it and they can't edit that after the fact.

[0058] We now describe a step-by-step example of a regulatory submission documentation workflow of how a user interacts with the system (200), corresponding to:

[0059] User Data Input (210): The user begins by submitting a set of documents to the system. For example, consider a healthcare regulatory submission scenario where the user inputs data pertaining to a medical diagnostic device for regulatory clearance.

[0060] User Classification (220): On the document upload step, the system (via the User Input Module 110) prompts the user with options for “Public” or “Private.” The user reviews the content and selects the appropriate classification. In our example, assume the record contains proprietary information about the medical diagnostic device, so the user selects "Private."

[0061] Conditional Data Route (240): The Data Routing Module (120) receives the classification and routes the data accordingly: If the user had chosen Public (225): The data would flow into Public Processing (245). The system would use the Public Al Model (250) to process the data (e.g., generate an embedding or answer). The result or embedding would be stored in the Public Vector Database (255). In this public scenario, because the data is not sensitive, the Blockchain logging (260) might be minimal – the system still records the transaction that data X was processed publicly at time Y by user Z, but the emphasis on strict logging is less than in the private case. The final output would be considered a General Access Output (265), meaning it could be viewable by users with general access rights. Since the user chose Private (230) in our example: The data goes into Private Processing (270). The Private Al Model (275) in the isolated environment processes the record. A Private Vector Database (280) stores the resulting embedding or intermediate data. Here, extensive Blockchain Logging (285) is triggered -- every step in the private pathway is rigorously logged given the higher sensitivity. The final output from this path is marked as a Secure / Restricted Access Output (290), only visible to users with clearance (likely the same user or certain authorized roles).

[0062] Federated Embedding Generation (235): In parallel or after the above, the system may perform federated embedding generation. This step is governed by system rules or user needs. For instance, if the user query or task requires insights from both private and public knowledge, the Federated Embedding Module (150) will combine context from both sides. If the task is self-contained (only private data needed), this might be skipped. In our example, perhaps the user's query asks, “Compare device clinical risks from proprietary test results with public test results.” The system would fetch private info (proprietary test results) and public info (public safety database search results) and generate federated insights.

[0063] Blockchain Authentication Layer (295): Throughout the workflow illustrated, the blockchain layer is omnipresent. In, element 295 represents the blockchain overlay monitoring all actions. It authenticates at the start (verifying the user's identity and permission to handle that patient data), logs the classification decision, logs the routing (e.g., "Data ID123 routed to Private Path at 10:01:30 by User A”), logs the model processing events (“Private model version X used at 10:01:32 on Data ID123"), logs embedding storage, logs any federated embedding creation, and finally logs the output generation and access (“User A viewed Secure Output for Data ID123 at 10:02:00"). Should any unauthorized attempt occur (say a user without clearance tries to mark data as public or access a private output), the blockchain layer would either prevent it via smart contract or record the attempt for security review.

[0064] Network and Hardware:schematically illustrates a non-limiting embodiment of the network and hardware architecture (300) designed to implement the secure information processing system, fulfilling the stringent requirements of data privacy regulations such as GDPR and HIPAA. This architecture is characterized by its strict multi-tenant logical and physical segregation, secure and private cloud-native data pathways, robust container security, comprehensive access controls, and a pervasive, distributed blockchain layer ensuring transparency and immutability of operations.

[0065] The system initiates with User / Client Devices (C), which interact with the system via an API Gateway (API_GW) that also encompasses the functionality of the User Input Module (110). This gateway serves as the single authorized point of entry, enforcing initial authentication, applying least-privilege principles, and acting as the interface where users explicitly classify their data as "public" or "private". All communication from client devices to the API Gateway is secured using end-to-end TLS 1.2+ encryption.

[0066] Incoming data, along with its classification, is then passed to the Data Processing & Routing Module (DR) (part of 120). This crucial component acts as a logical traffic controller. Based on the user's explicit data classification, the routing module directs the data into one of two physically and logically segregated environments: the Public Al Pathway or the Secure Tenant-Specific Private Al Pathway. This fundamental architectural design ensures that data classified as private never inadvertently enters the public processing domain.

[0067] The Public Al Pathway (housing parts of 130) is designed for non-sensitive, open-source-compatible data processing. It includes a Public Al Model Server (PIM), often leveraging enterprise-grade LLM services like Vertex Al (configured for no customer data retention, stateless inference, and no training on customer inputs), or other external public Al services (EAI). A Public Vector Database (PVD), implemented with services like Pinecone for public-domain indices, stores open-source language embeddings or other non-sensitive vector representations. This environment operates within isolated AWS / GCP Cloud Projects, yet can utilize external connectivity for public knowledge while adhering to strict security best practices.

[0068] Conversely, the Secure Tenant-Specific Private Al Pathway (housing parts of 140, 150, and 170) provides rigorous, isolated processing for highly sensitive and proprietary data. Each client is provisioned a dedicated AWS member account under AWS Organizations, creating effectively isolated infrastructure, runtime workloads, and data assets, reinforced by Service Control Policies (SCPs) and IAM permission boundaries. This environment, depicted with distinct boundaries, houses the Private Al Model Server (PPM), the Private Vector Database (PVD_S), the Federated Embedding Module (FEM), and the Secure Output & Storage (SOS).

[0069] Within this tenant-specific private enclave, private data and its derived embeddings and computational results never leave unless explicitly authorized by the user under strict controls. The Private Al Model operates on dedicated compute resources within isolated Private VPCs (in AWS or GCP Cloud Projects), segmented from shared infrastructure, ensuring no direct public exposure and adhering to zero-trust networking principles. VPC Endpoints route all internal traffic for maximum security. Containerized workloads within this environment are pre-approved and security-hardened via a rigorous CI / CD pipeline, including static scanning, behavioral testing, and manual security reviews, extending these controls to fine-tuned LLM and embedding model artifacts (e.g., Mistral OCR for document extraction workflows). The Private Vector Database (PVD_S), typically a tenant-specific Pinecone instance for private indices, stores sensitive embeddings on encrypted volumes (AES-256 via AWS KMS), with access strictly limited to components within this secure enclave.

[0070] The Federated Embedding Module (FEM) (150) is strategically placed within the Secure Tenant-Specific Private Al Pathway. When a query requires insights from both public and proprietary data, the FEM securely ingests publicly derived embeddings or insights from the Public Al Pathway. These public insights are brought into the private environment, where they are combined with private data for federated indexing and analysis, ensuring that the raw private data itself never traverses outside its secure boundary. A secure query-routing layer ensures no query or embedding ever crosses the boundary between public and private spaces, preventing private semantic data from leaking into public search contexts. The outputs or combined embeddings from the FEM are also processed and stored securely within this private environment. Final Al-generated results, whether from purely private processing or federated insights, are routed to the Secure Output & Storage (SOS) (170) module, which manages the secure delivery of results to the user and ensures that any sensitive outputs are stored in an encrypted, access-controlled manner. Observability and monitoring services (AWS CloudWatch, GCP Cloud Logging, Langfuse for prompt-level telemetry) collect real-time operational logs and metrics, with strict data residency ensuring logs remain within each client's dedicated environment. Versioned knowledge source histories provide auditable provenance.

[0071] Tying the entire architecture together is the Pervasive Blockchain Layer (160), consisting of distributed blockchain nodes. This layer acts as a tamper-resistant audit trail and policy enforcement mechanism. Blockchain Private Nodes (BCN_PVP), leveraging permissioned (e.g., Hyperledger Fabric based) implementations, are deployed within the Secure Tenant-Specific Private Al Pathway, monitoring and recording all operations involving sensitive data. Blockchain Public Nodes (BCN_PUB) may reside in the Public Al Pathway, tracking public data operations. These nodes communicate peer-to-peer to maintain a consistent, immutable ledger of all critical actions, including user classification decisions, routing decisions, model invocations (including specific LLM versioning), embedding generation, federated combinations, and output delivery. For enhanced accountability and compliance, critical administrative actions (e.g., infrastructure changes, permission escalations) can be optionally anchored to an Azure Blockchain (BCN_ADM) instance, backed by private hardware-token identities (HSM-backed) for immutable proof. External Auditor Nodes (BCN_EXT) can also participate in the blockchain network, providing independent verification of adherence to privacy policies and regulatory compliance, thereby fulfilling GDPR / HIPAA auditability requirements by design. Throughout the system, strict access controls are enforced, including IAM least-privilege principles, MFA, and Privileged Access Management (PAM) for just-in-time access, ensuring that no developer has access to client environments or data by design.

[0072] Figures 4A through 4E illustrate various graphical user interface (GUI) screens demonstrating an exemplary workflow for user-triggered secure information processing, specifically in the context of creating a regulatory submission, as per a non-limiting embodiment of the invention. These figures depict the front-end interactions for data input, user classification of data sensitivity, and granular control over the provenance of the generated output.

[0073] presents the initial "Upload Files" interface, which is part of the User Input Module (110). This screen is designed to facilitate the user's explicit classification of incoming data. It prominently features two distinct drag-and-drop areas: one clearly labeled "Public Data" and another labeled "Proprietary Data." Each section provides a "Browse files" button, allowing users to select documents from their local system. This visual and functional separation mandates that the user actively decides and segregates data based on its confidentiality at the point of ingestion, which is a core inventive feature. The interface indicates a file size limit (e.g., "Limit 200MB per file"), ensuring clarity for large files. After files are designated to their respective categories, corresponding "PROCESS DOCUMENTS" buttons are available for initiating the processing of each data type. A "SAVE RESPONSE" button suggests an option to store an overall generated output.

[0074] further clarifies the data input process by showing a standard file browser dialog invoked when a user clicks "Browse files." This dialog, overlaid on the "Upload Files" screen, shows a user navigating local directories that are themselves organized by data classification (e.g., "proprietary" and "public" folders). This reinforces the user's role in pre-categorizing and selecting files according to their sensitivity, aligning with the system's dual-pathway design.

[0075] depicts the "Upload Files" interface after documents have been selected and added to both the "Public Data" and "Proprietary Data" sections. For instance, files like "ljad335.pdf" and "cancers-2359725-supplementary.pdf" are listed under "Public Data," while "RMP.pdf" and "miRNA-SkinTumors_WO_2024170372_A1.pdf" appear under "Proprietary Data." The presence of multiple files demonstrates the ability to process batches of documents, all subject to the same strict classification and routing rules implemented by the Data Processing & Routing Module (120).

[0076] illustrates a critical aspect of the invention: the granular user control over the provenance of the Al-generated output. This screen allows the user to define, section by section, which type of data (public, proprietary, or a combination) should be leveraged for generating specific parts of the final document. For example, for "I. Introduction," the user can select "Proprietary," "Public," or "Dual" (the default is "DUAL," indicating insights from both sources via the Federated Embedding Module (150)). Similarly, for "II. Administrative Notes" and "III. Technical Documentation," the default is "PROPRIETARY_DATA," signifying that these sections should primarily draw from the private Al pathway. This interface directly implements the objective of allowing users to specify which portions of an Al-generated document can use private data, which should rely only on public data, and which can use both, ensuring that sensitive information is only included where explicitly allowed.

[0077] presents a sample of the final generated output document, titled "miRNA based IVD for Skin Tumor Detection." This document is constructed based on the input data uploaded in Figures 4A-4C and the provenance settings chosen in. The content flow, such as "Device Information" and "Administrative Notes," directly corresponds to the configurable sections. The Al system intelligently synthesizes information from both public and private knowledge bases (via the Federated Embedding Module, if "Dual" was selected for a section) to create a comprehensive yet privacy-compliant document. The presence of specific technical details and regulatory classifications demonstrates the system's ability to produce highly targeted, sensitive content for a regulatory submission by drawing from the user's proprietary data while potentially enriching it with public information, all under precise user control and with an auditable trail of its sourcing.

[0078] In light of the foregoing description, it should be evident how the objectives of the invention are met. The user-driven classification and granular control directly address the need for user empowerment and clarity in data handling. The dual pathways with federated combination solve the technical problem of utilizing both sensitive and open data without compromising the former. The blockchain layer ensures that this is not just a black-box claim but is verifiable and enforceable. No prior system or method provides this full-stack solution wherein an Al's usage of data is controlled at input, segregated in processing, combined securely, and audited immutably.

[0079] The invention can be embodied in various forms of software, firmware, or hardware. For instance, it could be delivered as an on-premise appliance to companies-a server (or cluster) that comes pre-loaded with the software components and an internal blockchain network connecting them. Alternatively, a cloud service provider could implement this as an offering where the control plane (blockchain and routing) is managed, and users upload their data to it with classification. In such a case, perhaps multiple tenants could share the blockchain for collective attestation but still have isolated pathways for their data. It's also conceivable to integrate parts of this invention with existing Al platforms: e.g., to add a blockchain audit layer to OpenAl's enterprise API, or to add a user classification UI to a collaboration software. The claims that follow intend to cover all such variations that fall within the scope and spirit of the invention.

[0080] The present invention has significant industrial applicability across numerous sectors that handle confidential, proprietary, or regulated data. This includes healthcare and life sciences for managing patient data (PHI) and clinical trial information; the financial sector for processing sensitive financial records and transaction data while complying with regulations like GDPR; the legal sector for handling privileged client information; and defense and national security for securing classified information. The system enables these industries to leverage advanced AI for analysis and decision-making without compromising data security or regulatory compliance, providing a verifiable and auditable framework for trusted AI operations.

[0081] Citation List follows:

[0082] Schmit, Andrew, Kevin Donahue, and Scott Titus. System and Method for Customizing Computer Vision Models for Infrared Cameras. U S Patent US12316753B1. 27 May 2025.

[0083] Schmit, Andrew, Kevin Donahue, and Scott Titus. System and Method for Customizing Computer Vision Models for Infrared Cameras. U S Patent US12316753B1. 27 May 2025.

[0084] Dahme, Harrison, and Nicholas Roberts‑Huntley. Privacy‑Preserving Transformer Model with Encrypted Dimensionality Reduction. U S Patent US12335379B1. 17 June 2025.

[0085] Helfgott, Adam, and Matthew Barlin. System and Method for Decentralized Data Management and Dynamic Verification. U S Patent US12155781B1. 26 Nov. 2024.

[0086] Yuan Xu, et al. Blockchain‑Based Generative Artificial Intelligence Detection and Evaluation Method and System. China Patent CN118520505B. 15 Nov. 2024.

[0087] Zhangye City Zhicheng Electronics Technology Co. Ltd. Network Information Security Comprehensive Analysis and Monitoring System and Method. China Patent CN118413359B. 31 Dec. 2024.

[0088] Ren, Junpeng. Data Management Method and System Based on Machine Learning. China Patent CN118312626B. 8 Oct. 2024.

[0089] Bao, Xuhua, et al. Security Protection Method, Device, Storage Medium and Computer Program Product. China Patent CN117725630B. 9 July 2024.

[0090] Michaelis, Oliver, Mike Ball, Charles A. H. Baker, and Peter A. Carides. Distributed Machine Learning Architecture with Hybrid Data Normalization, Proof of Lineage and Data Integrity. U S Patent US12032556B2. 9 July 2024.

[0091] [NPL1] Huang, Yu‑Hsiang, et al. “Transferable Embedding Inversion Attack: Uncovering Privacy Risks in Text Embeddings without Model Queries.” arXiv, arXiv:2406.10280, 2024.

[0092] [NPL2] Song, Congzheng, and Ananth Raghunathan. “Information Leakage in Embedding Models.” arXiv, arXiv:2004.00053, 2020.

Claims

A system for secure information processing, the system comprising:at least one processor; anda memory storing instructions that, when executed by the at least one processor, configure the system to comprise:a User Input Module configured to receive an input data item and an explicit classification for the input data item, the explicit classification designating the input data item as one of a 'private' classification or a 'public' classification;a Data Processing and Routing Module configured to, based solely on the explicit classification, route the input data item to one of two architecturally segregated processing pathways, comprising:a Private AI Pathway, an isolated secure computing environment to which data items with the 'private' classification are routed; anda Public AI Pathway distinct from the Private AI Pathway, to which data items with the 'public' classification are routed;wherein the Private AI Pathway is configured to process the data item with the 'private' classification using a private artificial intelligence model entirely within the isolated secure computing environment to generate a private AI result, such that the data item and the private AI result are confined to the isolated secure computing environment.The system of claim 1, further comprising a Blockchain Authentication Layer comprising a distributed ledger and configured to:record the explicit classification from the User Input Module as an immutable transaction on the distributed ledger; andenforce, by means of one or more smart contracts, the routing performed by the Data Processing and Routing Module by preventing any data item with the 'private' classification from being processed by the Public AI Pathway.The system of claim 1, further comprising a Federated Embedding Module, disposed within the isolated secure computing environment of the Private AI Pathway, configured to:receive a public data insight from the Public AI Pathway;combine the public data insight with a private data insight derived from the Private AI Pathway to generate a federated result; andensure the data item having the 'private' classification is not exposed outside the isolated secure computing environment during the generation of the federated result.The system of claim 1, further comprising a Secure Output Module configured to:receive an instruction to generate a composite output comprising a first portion derived from the Private AI Pathway and a second portion derived from the Public AI Pathway; andenforce a provenance rule that prevents the first portion from being exported outside the isolated secure computing environment.The system of claim 1, wherein the isolated secure computing environment of the Private AI Pathway is selected from the group consisting of: an on-premises server with no public network connectivity, a virtual private cloud (VPC) with network policies preventing external data egress, and a trusted execution environment (TEE) hardware enclave.A computer-implemented method for secure information processing, the method comprising:receiving, by a computing system having at least one processor, an input data item and an explicit classification for the input data item, the explicit classification designating the input data item as one of a 'private' classification or a 'public' classification;based solely on the explicit classification, routing the input data item to one of two architecturally segregated processing pathways, comprising a Private AI Pathway being an isolated secure computing environment, and a Public AI Pathway distinct therefrom;in response to routing the input data item with the 'private' classification to the Private AI Pathway, processing the input data item using a private artificial intelligence model entirely within the isolated secure computing environment to generate a private AI result; andconfining the input data item with the 'private' classification and the private AI result to the isolated secure computing environment.The method of claim 6, further comprising:recording the explicit classification as an immutable, cryptographically signed transaction on a distributed ledger of a blockchain layer; andutilizing a smart contract on the blockchain layer to enforce the routing, wherein the smart contract is configured to reject any attempt to process the input data item having the 'private' classification outside of the Private AI Pathway.The method of claim 6, further comprising:generating a public data insight in the Public AI Pathway;importing the public data insight into the isolated secure computing environment; andcombining, within the isolated secure computing environment, the public data insight with a private data insight from the Private AI Pathway to generate a federated result, without exposing the input data item having the 'private' classification outside the isolated secure computing environment.The method of claim 6, further comprising:receiving a user instruction specifying a provenance for a portion of a final output, the provenance selected from {private, public, dual};based on the specified provenance, assembling the final output; andin the case that a portion is designated with 'private' provenance, automatically redacting sensitive information from that portion prior to any external dissemination.A non-transitory computer-readable medium storing instructions which, when executed by a computing system comprising at least one processor, cause the system to perform the method of any one of claims 6-9..

Images