AI Engineer

Guardians of the State: An Air-Gapped AI Fortress for Consumer Data — Rachna Srivastava, DFPI

1953 summary words 9 min summary Watch video

Start with the signal

9 min read

Summary

At-a-Glance

  • Verdict: Watch fully
  • Core thesis: For high-stakes AI decisions involving sensitive consumer data and legal scrutiny, trust must be engineered into a physically isolated, replayable data-and-model architecture rather than delegated to cloud controls, compliance certifications, or model guardrails.
  • Why it matters: The talk offers a concrete control-plane pattern for secure AI operations: separate ingestion, data preparation, reasoning, PII protection, routing, learning, and evidentiary replay instead of treating an LLM as a self-contained solution.
  • Best use: Use it as an architecture review reference for any agent or AI system handling regulated data, consequential decisions, adversarial inputs, or requirements for auditability and post-hoc reconstruction.

Executive Summary

Rachna Srivastava of the California Department of Financial Protection and Innovation frames generative AI as a collapse of traditional digital trust: faces, voices, signatures, and other formerly credible signals can now be cheaply synthesized at scale. Her agency’s fraud systems therefore need to do more than produce useful detections; their outputs must be secure, explainable, reproducible, and defensible as evidence in court.

The central implementation lesson is that an LLM should be one component of a data pipeline, not a magic box expected to ingest and reason over raw multimodal evidence. DFPI’s initial offline implementation reportedly failed within two hours because live, messy inputs were pushed directly into the model. The redesigned system uses Kafka for burst buffering, ordered event logs, and replay; Spark for CPU-based normalization and validation; and the LLM specifically for reasoning over condensed, clean data.

The architecture adds layered controls around the model. Sensitive identifiers are converted through a SHA-256-based cryptographic vault backed by a hardware security module; a semantic router sends requests to the smallest suitable model; and a physical one-way data diode allows external threat intelligence into the isolated environment without creating a return path. Incoming data is quarantined and validated before entering production.

Most importantly, DFPI preserves the state needed to reconstruct a decision later. Kafka checkpoints enable event replay, while Apache Iceberg stores a queryable, immutable, time-versioned record so the agency can retrieve the relevant system state when a result is challenged. The speaker’s broader proposition is that in high-consequence AI, model quality is subordinate to a system’s ability to prove what happened, with what data, and under what controls.

Key Takeaways

  • Claim: High-stakes AI systems must be designed for evidentiary defensibility, not merely predictive performance. | Evidence: DFPI investigates fraud affecting California consumers, collects evidence, and expects defense attorneys to challenge every part of the system in court; the speaker identifies explainability and reproducibility at every decision point as mandatory system attributes. | Implication: For consequential agent workflows, retain sufficient input, event, model-routing, and system-state evidence to reconstruct a contested decision rather than relying on a generic model explanation after the fact.
  • Claim: Treating an LLM as a complete solution fails when raw, heterogeneous operational data is fed straight into model context. | Evidence: The team’s initial approach—an open-source model in an isolated environment with GPUs, prompts, guardrails, and live data—collapsed in two hours. Inputs included roughly 10 bank-statement formats, audio, screenshots, and faxed statements; after Spark cleaned and normalized them, the same model produced substantially better connections. | Implication: Prioritize ingestion, schema normalization, extraction, sequencing, and data quality before changing models or adding prompt guardrails; many apparent AI failures are pipeline failures.
  • Claim: Kafka is valuable in regulated AI not just for streaming scale but for ordered evidence and replayability. | Evidence: The system uses Kafka to buffer fraud-attack traffic spikes, preserve event sequence such as account opening and transactions, and move checkpoints back to the point of a decision to replay events; the speaker says this replay becomes courtroom proof. | Implication: Design agent and model pipelines as event-sourced systems where inputs and transformations can be replayed deterministically enough to investigate failures, disputes, and incident timelines.
  • Claim: In an isolated compute environment, semantic routing is a major capacity and cost lever. | Evidence: A single state-of-the-art model had been performing summarization, entity extraction, and fraud-ring detection. A semantic router instead selected the smallest capable model; DFPI reports that over 80% of tasks could use the smallest, fastest, cheapest model, enabling 3x more traffic with no additional GPUs and nearly 70% lower per-request processing cost. | Implication: Separate commodity processing from high-reasoning tasks and make model selection an explicit orchestration function, especially where GPU supply is capped or data cannot leave a controlled environment. | Caveat: These performance figures are specific to the speaker’s workload and model mix; routing accuracy and operational complexity need independent validation in another environment.
  • Claim: PII protection should minimize plaintext exposure in model memory and anchor key control in hardware when the stakes justify it. | Evidence: DFPI introduced a cryptographic vault using SHA-256 hashing and a hardware security module, with the relevant key physically attached to its server rack; the stated objective is to prevent exposed stored data from being intelligible without physical possession of the key. | Implication: Map exactly which fields models need in plaintext, replace or tokenize the rest before inference, and use hardware-backed key custody for the narrow workflows that require re-identification. | Caveat: Hashing is not inherently reversible redaction or suitable for every data-use case; the transcript does not specify tokenization, key rotation, re-identification controls, or how the system performs analysis that requires original values.
  • Claim: A physically enforced one-way boundary can let an air-gapped system learn from external intelligence without trusting firewall configuration. | Evidence: DFPI uses a one-way fiber data diode: an internet-connected laser transmitter sends data to a receiver inside the isolated system, with no internal transmitter back outward. External data first enters a quarantine zone, where Spark validation runs before it is admitted into production. | Implication: For crown-jewel AI environments, consider hardware-enforced directionality plus a quarantine-and-validation pipeline instead of treating a software firewall as the sole separation mechanism. | Caveat: A data diode constrains network-direction exfiltration, but it does not by itself guarantee overall security: malicious or poisoned inbound data, insider access, endpoint compromise, and physical operations still require controls.
  • Claim: Decision-time system state must be immutable and queryable years later if AI outputs may be contested. | Evidence: DFPI stores production data in Apache Iceberg, described as a time-travelled, queryable, immutable data store; when a result reaches court years later, the agency retrieves the system state at the time of the decision as evidence. Data is only revealed at the browser after multi-factor authentication for the person evaluating a threat case. | Implication: Build versioned provenance across data, transformations, prompts or policies, model versions, routing decisions, and access events; an audit log without recoverable decision context is insufficient for legal-grade reconstruction.

Detailed Brief

Security posture and its stated rationale

  • Claims: The speaker argues that encryption at rest and in transit does not fully solve model-security risk because data must be decrypted into model memory during processing.; She argues that private cloud endpoints and compliance certifications should not be equated with trustworthy system design.; Her design principle is that trust should be a physical property of architecture, hardware, and data flow rather than a policy promise or configuration setting.
  • Evidence: The talk cites prompt injection risk once plaintext is present in model memory.; It references the U.S. CLOUD Act as a concern for data held by cloud providers and characterizes FedRAMP, ISO, and SOC 2 as insufficient proof of resilience.; The solution keeps the core processing environment offline and only permits external learning data through a one-way physical transfer boundary.
  • Caveats: The presentation makes broad assertions about cloud access, prompt-injection exposure, certifications, and offline security without providing threat-model details, legal analysis, or comparative incident data.; Air-gapping creates material operational trade-offs: limited elastic compute, patching and model-update friction, hardware operations, and a need for carefully governed inbound data.
  • Implications: Threat modeling should distinguish confidentiality, integrity, availability, provenance, and legal-compulsion risks rather than collapsing all security requirements into an on-premises versus cloud decision.; Use physical isolation selectively for the highest-value data and most consequential workloads, where its operational cost is justified by the downside of compromise or inability to prove provenance.

Reusable end-to-end architecture pattern

  • Claims: The proposed stack assigns distinct jobs to distinct layers: Kafka for intake and replay, Spark for preprocessing and validation, LLMs for reasoning, a vault for sensitive-data protection, a semantic router for model allocation, a data diode for controlled learning, and Iceberg for historical reconstruction.; Data remains protected through most of the pipeline and is revealed only at the final browser-based evaluation step after multi-factor authentication.
  • Evidence: The speaker explicitly describes Kafka, Spark, the cryptographic vault, semantic router, data diode, quarantine zone, Apache Iceberg, browser access, and MFA as parts of one end-to-end system.; The architecture was presented as applicable beyond fraud detection to healthcare, banking, legal, and other sensitive domains.
  • Caveats: The transcript does not specify model-evaluation methodology, incident response procedures, identity and access-management design beyond MFA, retention rules, or how reproducibility is preserved across changing model weights and software dependencies.
  • Implications: A practical design review can evaluate each AI system by assigning accountable components for ingress control, transformation quality, inference, data minimization, routing, update intake, provenance, and human disclosure.; For agent systems, the same pattern suggests separating untrusted external tool outputs from production memory and recording the exact policy and tool state used for each action.

Notable Concepts & Terms

  • Defensible AI: An AI system whose outputs can be explained, reproduced, and supported with evidence when challenged in court or another formal review.
  • Kafka checkpoint and replay: Using ordered event streams and checkpoints to recreate the sequence and timing of inputs that led to an AI decision.
  • Spark preprocessing: CPU-cluster processing used to normalize and clean heterogeneous source materials before they enter expensive model context.
  • Cryptographic vault / HSM: A protection layer that converts sensitive values into cryptographic representations while anchoring key custody in hardware.
  • Semantic router: An orchestration layer that classifies a task and routes it to the smallest model capable of completing it, reducing constrained-compute costs.
  • One-way data diode: A physically enforced unidirectional transfer mechanism used here to ingest external threat intelligence without an outbound network path.
  • Quarantine zone: A pre-production landing area where externally sourced inputs are validated before they can affect the protected AI environment.
  • Apache Iceberg time travel: Querying historical table states so the system can retrieve decision-time data context years after an outcome was produced.

Operator Notes / Why Ken Should Care

  • Run a provenance-gap review for consequential AI workflows: verify that each output can be tied to immutable inputs, transformation versions, model/version selection, routing, policy context, human approvals, and access events.
  • Adopt semantic routing for agent and model workloads, with measured quality thresholds and fallback behavior; quantify what share of tasks can move off the largest model before adding GPU capacity.
  • Create a strict ingress tier for web, email, documents, tool outputs, and external intelligence: quarantine, validate, normalize, and label trust level before any content reaches durable memory or privileged agents.
  • Classify workloads that warrant a physically isolated or one-way-update environment, rather than applying air-gap architecture universally; include operational costs and non-network attack paths in the decision.
  • For PII-bearing AI systems, minimize model-visible plaintext and define a hardware-backed re-identification process with explicit authorization, audit, key rotation, and retention controls.

Source/Metadata

  • Title: Guardians of the State: An Air-Gapped AI Fortress for Consumer Data — Rachna Srivastava, DFPI
  • Transcript words: 3985
  • Duration seconds: 1272
  • Timestamp note: No timestamps or chapters were present in the supplied transcript. The transcript contains a substantial repeated segment after the initial conclusion.
Search this video Resume transcript at 0%
Full transcript 2179 words · 18 min read
0:00

By the time this presentation ends, someone somewhere will make life-altering decisions based on something generated entirely by AI.

0:13

For the last 30 years, digital infrastructure is based on these unwritten rules. If you see a face or you hear a voice, you trust someone behind it. If you see a signature, you trust someone has approved it. Every business transaction, every government workflow is based on this foundation of trust. So trust is an invisible layer. On top of it, all digital infrastructure is based. But generative AI trashed it completely. An AI agent can clone a voice. A synthetic face can bypass identity check. AI can impersonate people at a speed no criminal organization has been able to do before.

0:23

So in the era of generative AI, seeing is no longer believing, neither is hearing. The cost of deception has collapsed, and the speed of deception has exploded.

0:30

Hi, my name is Rachna Shirvaswa. I work for California Department of Financial Protection and Innovation. Our mission is to protect 39 million Californians and their financial identities. Let me tell you what we do. When a massive fraud attack happens in the state of California, we identify the fraud, we examine the fraud, and we run enforcement. Let me take you behind the scenes of what we actually do.

0:47

Fraud comes, we investigate the fraud. When the investigation happens, we collect all the evidence for the fraud. When we have all the evidence, we take that evidence to the court. And in the court, the defense attorney has only one job: to attack the system that we have built.

0:52

So the question arises: how should we build a system which is credible? What are the attributes we need to have in a system which can appear in the court? And appear in the court means the system should be defendable. Defendable means we should be able to explain the system at every step of the process. We should be able to reproduce the issue at every step of the process. Because everything, every data that we produce, is going to appear in the court. So how do you build that kind of system?

1:02

Since we deal with financial data, we have to ensure that the data is secure, for sure. We have to ensure that the data is evolving and learning. Why? Because the fraud space is changing every day. We have to ensure that the data is available to appear in the court and reproducible. So what I'm going to show you now is the system that we built and the lessons we have learned the hard way. So the first and foremost decision that we have taken was to build our solution offline. So you might be wondering, it's extreme. Why do you want to create a solution offline when we have a secure cloud?

1:17

So before we show you what we built, let's talk about what the industry does in the normal way. So the gold standard of security is encryption. Encryption means you encrypt the data at rest or encrypt the data in transit. But the thing is, for a machine learning model to work, the data has to be decrypted and available in plain text in the model memory. And if the data is already decrypted and present in plain text, it is prone to prompt injection attack.

1:19

Secondly, let's talk about private endpoints. Private endpoints are actually an isolated environment given to you from your cloud provider. So the thing is that according to the CLOUD Act, the federal government can access your data, which is in the cloud, and they don't even have to tell you that your data has been accessed. Let's talk about certification. FedRAMP compliant, ISO certified, SOC 2 compliant. All these compliance standards are just paper. And we have seen these highly compliant organizations fail over and over again. So the only way you can make your data secure and available in the court to present as evidence is to build the solution offline.

1:34

So like everyone else, we thought, what a big deal. Let's just download an open source model, create an isolated environment, spin up some GPU, add some system prompt, add some guardrails, and then we are running. Push the live data into it. We did the same as everyone else, and the system collapsed in two hours. And our first instinct was, we took a free model from online. The model is not good for our use case. But the issue was, we were treating the machine learning model as a magic box instead of as a data pipeline. So whatever garbage came into the system, we were expecting the model to clean up and do all the processing.

1:44

So to solve this problem, we introduced Kafka for data ingestion, Spark for data processing, and a large language model for reasoning. Three different tools to solve three different problems. We use Kafka for these three things. First, the data that enters into our system does not come at a consistent speed. When a fraud attack happens, it attacks all over the state. So we get a high spike of traffic into our system. So we needed a tool that can buffer that traffic so that the downstream component can access the data at a consistent speed. And Kafka did that.

1:53

Secondly, we wanted all the events that occur in the system to come and be stored in a sequential order. When did you open the account? When did the transaction happen? The order of events in the fraud is extremely important. Kafka helped us solve that problem. But the main problem that Kafka helped us solve is reproducibility. In Kafka, it lets you move the checkpoint to the point at which the decision was made, and it helped you replay the event. And this replayability of the event is the proof that we present in the courtroom.

2:02

So now Kafka did solve our data storage problem, but the data that enters into the system is really messy. We get 10 different formats of bank statement. We get audio file. We get screenshot, fax statement. And if you dump all this data to model memory, then no wonder the model hallucinates. So we introduced Spark because Spark let us process this data behind the scenes in clusters of CPU instead of working on GPU. And Spark let us clean the data, and then when we sent the clean data to the model memory, to our utter surprise, the same model started giving us such good results, it found the connection between the points which we never expected.

2:10

So we learned our first lesson. The lesson is most of the data problems in AI are data engineering problems wearing AI masks. So I recommend you consider using data engineering tools to solve those problems. Now our model memory is filled with very condensed clean data, but then we found our next issue. The issue was the memory was filled with a lot of sensitive information: your credit card number, your bank account number, your social security number.

2:18

So we introduced something called a cryptographic vault, which is basically a SHA-256 cryptographic algorithm with a hardware security module. So in the simple sense, it means that as we get the data into the system, the cryptographic vault converts the data into a cryptographic hash. The key that is used to do the conversion is physically attached to our server rack. So if tomorrow somebody is able to get our data, they have to walk into our office physically, break the server rack, get the key, to actually make sense of the data. Then we learned our second lesson. If the stakes are really high, trust hardware over software.

2:26

Now we have a model which is working really well. All the PII is redacted. We thought, let's just run a quick round of load testing and release this product. The problem is, in the cloud, the scaling is unlimited. You get a high spike of traffic, it spins up more servers, it distributes the load to the servers, and you are done.

2:29

But when you are creating an isolated environment, you have limited GPU, limited compute. So we have to step back and figure out what is the actual problem here. The problem was we were using one state-of-the-art machine learning model to do every single processing. The same model was doing the summarization, entity extraction, fraud ring detection. So we were actually making a neurosurgeon take the blood pressure of every single patient.

2:33

To solve this, we introduced a triage nurse, or semantic router. And the goal of semantic router is, as we get the data, it analyzes the data and forwards the request to the smallest possible model which is capable of processing that request. And by making this simple architecture change, we found that more than 80% of our tasks could be easily done by the smallest, fastest, cheapest model. And by not adding any new GPU, we could process three times more traffic, and the cost of processing each request reduced by nearly 70%.

2:37

Now we have done the unit testing, we have done the load testing, and then we found the hardest problem of all. The problem was, we built this highly secure system, but the system was not learning. The system did not know what is happening in the threat space. So the question arises: how do we make our system learn without creating a security hole? Usually in industry, people solve this problem by configuring a software firewall. But any configuration can be misconfigured. And once you have misconfigured it, your highly secure system will be a highly exploited one.

2:53

We decided not to trust the configuration, and we took help from physics. We introduced a one-way data diode, which is basically a fiber optics cable physically cut into half. The first half of the cable is connected to the internet to receive the data. The second half of the cable is connected to our solution. The first half of the cable has a laser transmitter, which receives the data from the internet and transmits the data to the second half. The second half has a laser receiver to receive the data from the first half, but there is no laser transmitter from our end to the outside world. So it is physically impossible for data to leak from the system. And this is how we ensure 100% guarantee of the security of the system.

2:56

The data diode solves the problem of directionality of the data. But anything entering into the data is considered to be unsafe until proven. So anything from outside first lands into a quarantine zone, where we run a Spark job that runs a validation on each input data. And then, if all the validation is successful, the data goes to the production layer.

3:02

In the production layer, we also save the data into Apache Iceberg. Apache Iceberg is a time-traveled, queryable, immutable data store. We enter the data in this data store because two years from now, if one of our results from our system goes to the court, we cannot go to the court and tell them, this system's result is produced by AI and we don't know anything about it. At that moment, we travel the Apache Iceberg, go to the point at which the decision was made, and get the state of the system at that moment from the database. And that state of the system appears as proof in the court.

3:11

And that is how we build a solution which is secure, which is evolving, and which is defensible in the court. This is the whole architecture end-to-end. If you see this, only at the very end of the system, when a user logs into the system, we authorize the user into multi-factor authentication, and only then is the data reverted. Data is not opened till the very end at the browser where the user is actually evaluating the threat case. So don't look at this solution as a fraud detection solution. This is the architecture of the future. Soon, the same architecture will be used to predict healthcare, banking statements, legal, and other domains.

3:32

In the end, I just want to say one thing. Build solutions that can be trusted. And remember, trust is not our policy. Trust is a physical property of the system. You have to build the trust from day one into your hardware, into your physics, into your architecture, or it's not there. It's that simple. So years from now, nobody will remember the models you trained. Nobody will remember the benchmark you received. People will only remember whether the solution that you have built can be trusted when it is needed the most. Thank you so much. Thank you so much. We have to ensure that the data is evolving and learning. Why? Because the fraud space is changing every day.

4:00

We have to ensure that the data is available to appear in the court and reproducible. So what I'm going to show you now, the system that we built, and the lessons we have learned the hard way. So the first and foremost decision that we have taken was to build our solution offline. So you might be wondering, like, it's extreme. Like, why are you, why do you want to create a solution offline when we have a secure cloud? So before we show you what we build, let's talk about what do industry do in the normal way. So the gold standard of security is encryption. Encryption means you encrypt the data at rest or encrypt the data on the transit.

5:06

That means the thing is, but for machine learning model to work, the data has to be decrypted and available in the plain text in the model memory. And if the data is already decrypted and present in the plain text, it is prone to prompt injection attack. Secondly, let's talk about private endpoints. Private endpoints are actually an isolated environment given to you from your cloud provider.

5:50

So the question, the thing is that according to the cloud act, federal government can access your data, which is in the cloud, and they don't even have to tell you that your data has been accessed. Let's talk about certification. FedRAM compliant, I also certified SOC 2 compliant. All these compliance are just paper. And we have seen these highly compliant organizations fail over and over again. So only way you can make your data secure to be available in the court to present as evidence as evidence is to build the solution offline.

6:53

So like everyone else, we thought, like, what a big deal. Let's just download an open source model, create an isolated environment, spin up some GPU, add some system prompt, and add some guardrails, and then we are running, push the live data into it. We did the same like everyone else. And the model, the system collapsed in two hours. And our first instinct was, you know, we took the model, free model from online. Model is not good for our use case. But the issue was, we were treating machine learning model as a magic box, instead of as a data pipeline. So anything that garbage comes into the system, we were expecting the model to clean up and do all the processing.

7:57

So to solve this problem, we introduced Kafka for data ingestion, Spark for data processing, and large language model for reasoning. Three different tools to solve three different problems. We use Kafka for these three things. First, the data that enter into our system does not have come at a consistent speed. When a fraud attack happen, it attack all over the state. So we get a high spike of traffic into our system. So we needed a tool that can buffer that traffic, so that the downstream component can access the data at a consistent speed. And Kafka did that. Secondly, we wanted all the events that occur in the system to come and store in a sequential order.

9:04

When did you open the account? When did the transaction happen? The order of events in the fraud is extremely important. Kafka helped us solve that problem. But the main problem that Kafka helped us solve is reproducibility. In Kafka, it let you move the checkpoint to the point at which the decision was made, and it helped you replay the event. And this replayability of the event is the proof that we present in the courtroom. So now Kafka did solve our data storage problem, but the data that enter into the system is really messy. We get 10 different format of bank statement. We get audio file. We get screenshot, fax statement.

10:04

And if you dump all this data to model memory, then no wonder model hallucinate. So we introduced Spark because Spark let us process this data behind the scene in the clusters of CPU, instead of working on GPU. And Spark let us clean the data, and then when we process, send the clean data to the model memory, to our utter surprise, the same model started giving us so good results, it found the connection between the points which we never thought expected.

10:53

So we learn our first lesson. The lesson is most of the data problem in AI are data engineering problem wearing AI mask. So I recommend you to consider using data engineering tool to solve those problems. Now our model memory is filled with a very condensed clean data, but then we found our next issue. The issue was the memory was filled with a lot of sensitive information, your credit card number, your bank account number, your social security number. So we introduced something called cryptographic vault, which is basically a SHA-256 cryptographic algorithm with hardware security module.

11:50

So in the simple sense it means that as we get the data into the system, cryptographic vault, which converts the data into cryptographic hash. is the key that is used to do the conversion is physically attached to our server rack. So if tomorrow somebody is able to get our data, they have to walk into our office physically, break the server rack, get the key to actually make sense of the data. So we have to do the data. So we have to do the data. Then we learn our second lesson. If the stakes are really high, trust hardware over software.

12:41

Now we have a model which is working really well. All the PII is redacted. We thought, let's just run a quick round of load testing and release this product. The problem is in the cloud, the scaling is unlimited. You get a high spike of traffic. It spins up more server. It distributes the load to the server and you are done. But when you are creating an isolated environment, you have limited GPU, limited compute, limited and you have to do it. So we have to step back and figure out what is the actual problem here. The problem was we were using one state of the art machine learning model to do every single processing.

13:35

The same model was doing the summarization, entity extraction, fraud ring detection.

13:45

So we were actually making a neurosurgeon take the blood pressure of every single patient. To solve this, we introduce triage nurse or semantic router. And the goal of semantic router is, as we get the data, it analyzes the data and forward the request to the smallest possible model which is capable of processing that request. And by making this simple architecture change, we found that more than 80% of our tasks could be easily done by the smallest, fastest, cheapest model. And by not adding any new GPU, we could process three times more traffic and cost of processing each request reduced to nearly 70%.

14:55

Now we have done the unit testing, we have done the load testing, and then we found the hardest problem of all. The problem was, we built this highly secure system, but the system was not learning. System did not know what is happening in the thread space. So the question arises, how do we make our system learn without creating a security hole?

15:35

System is not learning. Usually in industry, people solve this problem by configuring software firewall.

15:44

But any configuration can be misconfigured. And once you have misconfigured, your highly secure system will be highly exploited one. We decided to not trust the configuration and we took help from physics. We introduced one-way data diode, which is basically a fiber optics cable physically cut into half. The first half of the cable is connected to the internet to receive the data. Second half of the cable is connected to our solution. First half of the cable has laser transmitter, which receives the data from the internet and transmit the data to the second half. Second half has a laser receiver to receive the data from the first half.

16:41

Second half, but there is no laser transmitter from our end to the outside world. So it is physically impossible for data to leak from the system. And this is how we ensure 100% guarantee of the security of the system.

17:09

Data diode solves the problem of directionality of the data. But anything entered into the data is considered to be unsafe till proven. So anything from outside first lands into quarantine zone. where we run a Spark job that runs a validation on each input data. And then all the validation is successful. Then the data goes to the production layer. In the production layer. We also save the data into Apache Iceberg. Apache Iceberg is a time-traveled, queryable, immutable data store.

18:02

We enter the data in this data store because two years from now, one of our results from our system goes to the court. We cannot present, we cannot go to the court and tell them, you know what, this system's result is produced by AI and we don't know anything about it. At that moment, we travel the Apache Iceberg, go to the point at which the decision was made and get the state of the system at that moment from the database. And that state of the system appear as a proof in the court. And that is how we build a solution which is secure, which is evolving and which is defensible in the court.

19:07

This is the whole architecture end-to-end. If you see this only at the very end of the system, when a user logs into the system, we authorize the user into multi-factor authentication and only then the data is reverted. Data is not opened till the very end at the browser where the user is actually evaluating the threat case.

19:44

So don't look at this solution as a fraud detection solution. This is the architecture of the future. Soon, the same architecture will be used to predict the healthcare, banking statements, legal and other domains. In the end, I just want to say one thing. Build solution that can be trusted. And remember, trust is not our policy. Trust is a physical property of the system. You have to build the trust from day one into your hardware, into your physics, into your architecture, or it's not there. It's that simple. So years from now, nobody will remember the models you trained. Nobody will remember the benchmark you received.

20:41

People will only remember the solution that you have built can be trusted when it needed. The most. Thank you so much. Thank you so much.

Reading tools

Type to find a passage

Appearance
Ask this transcript

Notebook

Export Markdown

Add a note