# Workshop 12: Case Studies and Real-World Applications - AIShield > The capstone of the program: revisit every thread - attacks, defenses, privacy, fairness, and trust - through real deployments, using AIShield's AI-security case-study materials and a federated-learning-with-differential-privacy lab. ## Overview This is the final workshop, and it is deliberately different from the eleven that precede it. Rather than introduce a new attack or a new defense, it looks back across the whole program and asks how these ideas hold up in production. The organizing lens is **AIShield**, a Bosch venture that builds tooling to secure machine-learning and generative-AI systems, and a set of case studies drawn from its work and from the program's own labs. Each case study is a real problem with a real threat, a technique the earlier workshops taught, and a trade-off that cannot be avoided. The goal is not to add more theory but to integrate what you already know into the judgment that deploying a secure AI system actually requires. The workshop is built around four case studies, each tied back to an earlier session: adversarial robustness for content and spam detection (the evasion and robustness arc of Workshops 3 through 5), privacy-preserving healthcare machine learning (the differential privacy and federated learning of Workshop 6), fairness mitigation in hiring systems (the bias-and-fairness work of Workshop 7), and the security of federated learning itself against Byzantine and backdoor attacks (again Workshop 6, with the poisoning threat of Workshop 5). The hands-on lab implements the second of these directly: a federated system trained with formal differential-privacy guarantees. **Prerequisites:** This capstone assumes the full program. It leans most heavily on [Workshop 6: AI and Privacy - Differential Privacy and Federated Learning](../Workshop06/AI_and_Privacy_Differential_Privacy_and_Federated_Learning.md), whose federated-learning and differential-privacy machinery the lab extends, on Workshops 3 through 5 (adversarial attacks and robustness), and on Workshop 7 (bias and fairness). Complete those first; the case studies here are written as a synthesis of them, not a fresh start. ## Workshop Video This session is a case-study capstone rather than a guest lecture or panel. There is no single speaker; instead the material is organized around AIShield's published case studies and the program's own labs, so you work through the reading and the notebooks below. **Case Study Walkthrough:** Coming Soon - the recorded walkthrough of the AIShield case studies and the federated-learning-with-differential-privacy lab will be added here once published. ## Learning Objectives After completing this workshop, you will be able to: - Describe, factually and without marketing framing, what an AI-security platform such as AIShield does: model-vulnerability assessment, adversarial-robustness hardening, and runtime guardrails for large language models across the model lifecycle. - Trace each of four production case studies back to the workshop that supplied its technique, and name the specific threat each one defends against. - Explain the security-versus-accuracy trade-off in adversarial robustness, the privacy-versus-utility trade-off in differential privacy and federated learning, and the fairness-versus-accuracy trade-off in bias mitigation, and argue why none of them can be eliminated. - Explain how federated learning both mitigates a privacy risk (raw data stays local) and opens a new attack surface (malicious clients), and describe robust-aggregation defenses against Byzantine and backdoor attacks. - Build a federated learning system with differential privacy in TensorFlow Federated, calibrate the noise multiplier against a stated privacy budget, and read off the resulting $(\epsilon, \delta)$ guarantee. - Synthesize the program's full arc - fundamentals, threat models, attacks, robustness, privacy, fairness, trust, secure development, governance, and deployment - into a coherent account of what it takes to field a trustworthy AI system. ## Theoretical Background ### AIShield: Securing AI Across the Lifecycle AIShield is a venture of Bosch (Bosch Global Software Technologies) that provides tooling to secure machine-learning and generative-AI systems. Its stated aim is to treat AI security as a first-class concern rather than an afterthought, on the observation that as organizations adopt AI, the threat and attack surface expands in ways that conventional information-security and application-security controls do not fully cover. According to its own case-study materials, the platform, marketed as SecureAIx, is organized into modular offerings: - **Watchtower** - securing AI code and the software supply chain that produces a model. - **AISpectra** - automated risk and vulnerability assessment of a model, probing it for weaknesses such as model extraction, evasion, and poisoning exposure. - **Guardian** - runtime guardrails for generative-AI and LLM applications, enforcing policies against prompt injection, sensitive-information disclosure, and insecure output handling. The company describes its technology as patented and production-optimized, developed through several years of research at Bosch, and reports adoption across high-tech, banking, healthcare, telecommunications, automotive, and manufacturing organizations, along with recognition in the 2023 Gartner AI TRiSM (Trust, Risk, and Security Management) Market Guide. These figures come from AIShield's promotional materials and are reproduced here as context, not as independent verification. What matters pedagogically is the shape of the offering: it maps almost one-to-one onto the program. Supply-chain and secure-development concerns are Workshop 9; automated vulnerability assessment is the attack-and-robustness arc of Workshops 3 through 5; LLM guardrails, prompt injection, and governance align with Workshops 10 and 11. The case studies below make those connections concrete. ### The Four Case Studies Each case study follows the same shape: the **problem** (what the system is for), the **threat** (what an adversary or a flaw does to it), the **technique** (what the program taught to address it), and the **trade-off** (what it costs). Read them as applications, not new material. #### Case Study 1 - Adversarial Robustness in Content and Spam Detection **Problem.** Filters that classify email as spam or content as malicious or benign are deployed at enormous scale and are continuously probed by the very adversaries they are meant to stop. A spam filter that works in the lab is worthless if it can be walked past in production. **Threat.** Evasion attacks. As in Workshops 3 and 4, an attacker crafts inputs with small, targeted perturbations - reworded text, feature-space manipulation, adversarial tokens - that flip the classifier's decision while leaving the message's function intact. The defender rarely sees the attack coming and cannot retrain instantly. **Technique.** The robustness pipeline of Workshops 3 through 5: assess the deployed model against known evasion attacks to measure its true attack-success rate, then harden it with adversarial training, input validation, and ensembling, and monitor for adversarial patterns continuously so defenses adapt as attacks evolve. This is exactly the assess-then-harden loop that automated tools like AIShield's AISpectra are built to run. **Trade-off.** Security versus clean-data performance. Adversarial training raises robustness but tends to lower accuracy on ordinary inputs and can push the false-positive rate up, so legitimate mail gets caught. The engineering task is to buy enough robustness without degrading the day-to-day experience past what the business will tolerate - the same robustness-accuracy tension named in Workshop 5. #### Case Study 2 - Privacy-Preserving Healthcare Machine Learning **Problem.** Several hospitals want to jointly train a diagnostic model that is better than any one of them could train alone, but the training data is sensitive patient information under regimes such as HIPAA, and it cannot be pooled into a central dataset. **Threat.** Centralizing the data would create a single high-value target and violate patient privacy outright. Even without centralization, a trained model can leak its training data through membership inference and model inversion, and, as Workshop 6 showed with Deep Leakage from Gradients, the model updates a client shares are themselves near-invertible functions of its private data. **Technique.** The Workshop 6 stack: **federated learning** so each hospital trains locally and shares only model updates, **differential privacy** so those updates are clipped and noised to a formal $(\epsilon, \delta)$ bound tracked by a privacy accountant, and **secure aggregation** so the server sees only the combined update, never any single hospital's. This workshop's lab implements the federated-learning-plus-differential-privacy portion of this stack. Together these turn "the data stayed on the device" from an architectural hope into a measurable guarantee. **Trade-off.** Privacy versus utility. A smaller privacy budget $\epsilon$ means more noise and lower diagnostic accuracy; federated training adds communication cost and must cope with non-IID data across hospitals. There is no setting that maximizes both privacy and accuracy - privacy engineering is choosing an operating point on that curve that the clinical application can live with, with the affected stakeholders in the room. #### Case Study 3 - Fairness Mitigation in Hiring AI **Problem.** A company uses a model to screen resumes at a scale no human team could match. Historical hiring data, however, encodes past human bias, so a model trained to imitate it will reproduce and can amplify that bias - and do so under anti-discrimination law. **Threat.** Disparate impact. Left unmitigated, the model passes candidates from different demographic groups at systematically different rates, producing discriminatory outcomes and legal and reputational exposure. The "adversary" here is not an attacker but the data itself and the harm it encodes, the ethics-and-fairness problem of Workshop 7. **Technique.** The Workshop 7 toolkit: measure fairness with explicit metrics - demographic parity, equalized odds, predictive parity - then mitigate at one or more stages. **Pre-processing** reweights or rebalances the training data; **in-processing** adds a fairness constraint to the training objective; **post-processing** calibrates decision thresholds per group. A combined approach can bring pass rates across groups into alignment. **Trade-off.** Fairness versus accuracy, and fairness versus fairness. Enforcing parity typically costs a few points of accuracy, and, as Workshop 7 established, the fairness metrics are mutually incompatible in general - you usually cannot satisfy demographic parity, equalized odds, and predictive parity at once - so the choice of which definition to enforce is a value judgment that must be made explicitly, not a purely technical one. #### Case Study 4 - Security of Federated Learning: Byzantine and Backdoor Attacks **Problem.** A federated system trains a shared model across many devices with no central authority that can vet the participants - for example a fleet of medical devices. The privacy benefit of keeping data local comes bundled with a new trust problem: some of those participants may be malicious. **Threat.** Two attacks from the distributed setting of Workshop 6. In a **Byzantine attack**, compromised clients send arbitrary or coordinated malicious gradients to corrupt the aggregated model; with a naive average, even a small colluding fraction can drive accuracy toward chance. In a **hidden-trigger backdoor attack**, a malicious client poisons its update so the global model behaves normally on clean inputs but misclassifies any input carrying a specific trigger pattern - a poisoning threat, invisible to ordinary accuracy metrics, that federated aggregation then spreads to every client. **Technique.** Robust aggregation replaces the naive weighted mean. **Coordinate-wise median** and **trimmed mean** discard outlier updates; **Krum** (Blanchard et al., 2017) selects the update closest to its neighbors on the assumption that honest gradients cluster while malicious ones do not. These are layered with differential privacy on the gradients and continuous monitoring of update statistics to flag anomalies. The result tolerates a bounded fraction of Byzantine clients. **Trade-off.** Robustness versus convergence and accuracy. Robust aggregators throw away information to resist outliers, which slows convergence and can lower final accuracy, and they hold only up to a fraction of malicious clients - past that threshold the defense fails. Decentralization removes one risk (a central data store) and introduces another (untrusted participants), and the defenses against the second are not free. ### Mapping the Case Studies to the Program | Case study | Problem domain | Primary threat | Technique applied | Core trade-off | Draws on | |------------|----------------|----------------|-------------------|----------------|----------| | 1. Content and spam detection | Classification at scale | Evasion / adversarial examples | Robustness assessment, adversarial training, monitoring | Security vs. clean accuracy | Workshops 3-5 | | 2. Healthcare ML | Multi-party clinical diagnosis | Data leakage, model inversion, gradient leakage | Federated learning + differential privacy + secure aggregation | Privacy vs. utility | Workshop 6 (this lab) | | 3. Hiring AI | Resume screening | Disparate impact / discrimination | Fairness metrics + pre/in/post-processing mitigation | Fairness vs. accuracy (and vs. fairness) | Workshop 7 | | 4. Federated learning security | Decentralized training | Byzantine attacks, hidden-trigger backdoors | Robust aggregation (median, trimmed mean, Krum) + DP | Robustness vs. convergence | Workshops 6, 5 | ### The Whole Program in One View Placed end to end, the twelve workshops trace a single argument about building AI systems that can be trusted in the world. It begins with **fundamentals** (Workshop 1) and the **threat models** that name what can go wrong (Workshop 2). It then studies the **attacks** in depth - white-box and black-box evasion (Workshops 3 and 4) - and the **robustness** that resists them (Workshop 5). It turns from the model's outputs to its inputs with **privacy**, differential privacy and federated learning (Workshop 6), and from privacy to **ethics**, measuring and mitigating bias (Workshop 7). It asks how to make models understandable enough to **trust** through transparency and explainability (Workshop 8), then how to **develop** them securely (Workshop 9), how to **govern** them under emerging regulation and standards (Workshop 10), and how to **deploy and operate** them safely in production (Workshop 11). This capstone (Workshop 12) closes the loop by showing all of it at once in **real-world** deployments. Attacks motivate defenses; defenses meet privacy and ethics; those meet trust, development, governance, and deployment; and the whole assembly is what a case study like AIShield's is trying to deliver. No single technique makes a system secure - security is the integration of all of them, chosen against explicit trade-offs. ## Hands-on Lab The lab makes Case Study 2 real. It is built on **TensorFlow** and **TensorFlow Federated (TFF)**, the framework for simulating federated computations, and uses Google's **`dp_accounting`** library to compute the formal privacy guarantee. It extends the federated-learning-and-differential-privacy material of Workshop 6 into a complete DP-FedAvg pipeline: build a federated system, then calibrate the differential-privacy noise so the released model comes with a stated $(\epsilon, \delta)$ bound. (Note: the two notebooks use TensorFlow Federated, not the PyTorch/Opacus stack from the Workshop 6 labs - the concepts are identical; only the framework differs.) ### Activity 01 - Federated Learning with Differential Privacy (Part 1) Build a federated learning system in TensorFlow Federated: use the pre-partitioned federated EMNIST dataset across many simulated clients, construct the client and server models, run FedAvg over multiple rounds, and integrate differential privacy into the training loop (DP-SGD embedded in federated averaging). The notebook also explores the non-IID heterogeneity of federated data - why the examples on each simulated device differ - and visualizes model performance under privacy-preserving training. - Open on GitHub: [SecureAI_Workshop12_FL_with_DP_P01.ipynb](https://github.com/SecureAI-luc/SecureAI-Lab/blob/main/Workshop12/SecureAI_Workshop12_FL_with_DP_P01.ipynb) | Open in Colab: [SecureAI_Workshop12_FL_with_DP_P01.ipynb](https://colab.research.google.com/github/SecureAI-luc/SecureAI-Lab/blob/main/Workshop12/SecureAI_Workshop12_FL_with_DP_P01.ipynb?authuser=1) ### Activity 02 - Federated Learning with Differential Privacy (Part 2) Calibrate the privacy guarantee. Using DP-FedAvg on the federated EMNIST dataset, sweep the noise multiplier to find how much noise the model can tolerate, use `dp_accounting` to convert the chosen parameters into an exact $(\epsilon, \delta)$ bound, and train a final private model for release. The activity makes the privacy-utility trade-off measurable: you watch accuracy fall as the privacy guarantee tightens and choose a defensible operating point. - Open on GitHub: [SecureAI_Workshop12_FL_with_DP_P02.ipynb](https://github.com/SecureAI-luc/SecureAI-Lab/blob/main/Workshop12/SecureAI_Workshop12_FL_with_DP_P02.ipynb) | Open in Colab: [SecureAI_Workshop12_FL_with_DP_P02.ipynb](https://colab.research.google.com/github/SecureAI-luc/SecureAI-Lab/blob/main/Workshop12/SecureAI_Workshop12_FL_with_DP_P02.ipynb?authuser=1)
To run either activity, open its Colab link and use **File -> Save a copy in Drive** to get your own editable copy, then execute it there. ## Key Takeaways - A production AI-security offering such as AIShield's SecureAIx maps directly onto the program: supply-chain and secure development, automated vulnerability assessment, and runtime guardrails for generative AI are the same concerns the workshops taught, packaged for deployment. - Every case study is an application of an earlier workshop plus an unavoidable trade-off: robustness costs clean accuracy, privacy costs utility, fairness costs accuracy (and the fairness metrics conflict with each other), and robust aggregation costs convergence speed. - Federated learning cuts both ways: keeping raw data local mitigates a privacy risk but opens a new attack surface for Byzantine and backdoor attacks, which is why it is paired with differential privacy, secure aggregation, and robust aggregation. - The healthcare lab shows the privacy-utility curve in the numbers: a smaller $\epsilon$ means more noise and lower accuracy, and calibrating the noise multiplier against a stated privacy budget is the core engineering decision. - Security is not a single technique but the integration of attacks, defenses, privacy, ethics, trust, secure development, governance, and deployment - chosen deliberately against trade-offs, which is what real-world deployment demands. ## Additional Resources - **AIShield case studies - ML and GenAI (2024) (PDF):** [[`Case+Studies+-+ML+++GenAI+-+2024+_2_.pdf`](https://github.com/SecureAI-luc/SecureAI-Lab/blob/main/Workshop12/docs/Case+Studies+-+ML+++GenAI+-+2024+_2_.pdf) - AIShield's own account of securing ML and generative-AI systems across industries, including LLM guardrail deployments. - **AIShield platform overview (FCD) (PDF):** [`AIShield_FCD_0624-1.pdf`](https://github.com/SecureAI-luc/SecureAI-Lab/blob/main/Workshop12/docs/AIShield_FCD_0624-1.pdf) - the SecureAIx platform and its Watchtower, AISpectra, and Guardian offerings. - **AIShield - Guardian Enterprise Sandbox for GenAI (blog):** [boschaishield.com](https://boschaishield.com/resources/blog/unveiling-guardian-enterprise-sandbox-a-cxos-introduction-to-safe-secure-and-compliant-gen-ai-deployments/) - a vendor introduction to safe, secure, and compliant generative-AI deployment. - **TensorFlow Federated:** [tensorflow.org/federated](https://www.tensorflow.org/federated) - the framework the lab notebooks are built on for simulating federated learning. - **Google `dp_accounting`:** [github.com/google/differential-privacy](https://github.com/google/differential-privacy) - the privacy-accounting library the Part 2 notebook uses to compute the $(\epsilon, \delta)$ guarantee. - **McMahan et al. (2017), "Communication-Efficient Learning of Deep Networks from Decentralized Data" (FedAvg):** [arxiv.org/abs/1602.05629](https://arxiv.org/abs/1602.05629) - the federated averaging protocol the lab implements. - **Abadi et al. (2016), "Deep Learning with Differential Privacy" (DP-SGD):** [arxiv.org/abs/1607.00133](https://arxiv.org/abs/1607.00133) - per-example clipping, Gaussian noise, and the accountant behind differentially private training. - **Blanchard et al. (2017), "Machine Learning with Adversaries: Byzantine Tolerant Gradient Descent" (Krum):** [proceedings.neurips.cc](https://proceedings.neurips.cc/paper/2017/hash/f4b9ec30ad9f68f89b29639786cb62ef-Abstract.html) - the robust-aggregation defense in Case Study 4. - **[Workshop 6: AI and Privacy - Differential Privacy and Federated Learning](../Workshop06/AI_and_Privacy_Differential_Privacy_and_Federated_Learning.md)** - the differential-privacy and federated-learning foundations this lab extends. - **[Program Resource Library](../resources.md)** - shared papers, tools, and datasets for the full workshop series. ## Next Steps This is the final workshop. Continue to the [Program Conclusion: Organizational Framework and Next Steps](../program_conclusion.md), which pulls the four-phase secure-AI framework together and points toward what comes after the program, or return to the [program home page](../index.md) to revisit any earlier workshop.