Part 6 of the FDE skills series. FDEs work inside the customer’s walls. In healthcare, finance, pharma and defense, those walls are there for good reasons. This part covers the security, privacy and compliance skills that let you work inside them without slowing everything down. Nothing here is legal advice; always confirm obligations with the customer’s counsel and compliance team.
1. Why this is part of the FDE job
Aater Suleman made the point in his Dallas talk that the FDE role grows out of a simple fact: to deliver value, someone has to embed with the customer. In regulated industries, embedding means handling patient records, financial data or controlled information, working under the customer’s security policies, and convincing people whose job is to say no.
Many promising AI projects don’t die on accuracy. They die in the security review. An FDE who understands security and compliance can turn a months-long approval into weeks, because they design the system to pass review from the start instead of retrofitting controls at the end.
The good news: most of what reviewers want follows a small set of principles. Learn them once and you’ll recognize them in every framework.
2. Five principles that satisfy most reviewers
| Principle | What it means for an AI system |
|---|---|
| Least privilege | The AI gets only the access it needs for this task, through a dedicated, scoped account |
| Data minimization | Use the least sensitive data that works: de-identified, sampled, or synthetic first |
| Know where data goes | Document every place data travels, including model providers and logs |
| Traceability | Log every model call, tool call and data access; keep an audit trail |
| Human accountability | A named person approves high-impact actions and owns each decision |
These map directly to Aater’s “earn the right to write.” Starting read-only, with minimal data, under a scoped account, is not only good engineering. It’s the fastest path through review.
3. Handling sensitive data
Know your data classes
Before touching any data, ask the customer how it’s classified. Typical classes include public, internal, confidential, and regulated data such as protected health information (PHI), payment card data or personal data covered by privacy laws. Each class comes with rules about where it can be stored, who can see it and whether it can leave the customer’s environment.
Healthcare: the HIPAA basics every FDE should know
If you work with US healthcare organizations, a few HIPAA concepts come up constantly:
- Business Associate Agreement (BAA). A vendor that handles PHI on behalf of a covered entity generally needs a BAA in place before touching the data. That includes your company, and often your cloud and model providers too.
- Minimum necessary. Use and disclose only the minimum PHI needed for the purpose. Design prompts, retrieval and logs with that in mind.
- De-identification. HIPAA describes two routes: the Safe Harbor method, which removes 18 specified types of identifiers, and Expert Determination by a qualified expert. De-identified data is far easier to work with during prototyping.
Practical data-handling rules
- Never paste real customer data into a personal or consumer AI tool. Use only environments and providers approved by the customer.
- Check what the model provider keeps. Ask about data retention, training use and where processing happens. Many enterprise offerings support zero-data-retention options; confirm the terms in writing.
- Treat logs as sensitive data. Prompts, retrieved documents and outputs often contain the very information you were trying to protect. Apply the same retention and access rules.
- Mask by default. Strip or tokenize identifiers before they reach the model whenever the task allows.
- Keep data where it lives when you can. Deploying inside the customer’s cloud account or network often removes whole categories of review questions.
4. AI-specific threats
AI systems add new ways to fail that traditional security reviews may not cover. The OWASP Top 10 for Large Language Model Applications is a good starting list; prompt injection sits at the top of it. The threats I see most often in agent projects:
| Threat | What happens | Defense |
|---|---|---|
| Prompt injection | Instructions hidden in an email, document or web page hijack the agent | Treat all retrieved content as untrusted; limit tools; require approval for sensitive actions |
| Sensitive data disclosure | The model reveals data the user shouldn’t see | Enforce the user’s permissions at retrieval time; output filtering |
| Excessive agency | The agent has more tools or permissions than the task needs | Least privilege per task; read-only by default; value and rate limits |
| Insecure output handling | Model output is executed or inserted into systems without checks | Validate and sanitize outputs like any untrusted input |
| Supply-chain risk | Third-party models, plugins or connectors introduce vulnerabilities | Approved component list; version pinning; vendor review |
A key design rule for retrieval systems: the AI should never see more than the person it’s acting for is allowed to see. Enforce document permissions when you retrieve, not after the model has already read everything.
5. Speaking the compliance language
You don’t need to be a lawyer, but you need to recognize the frameworks your customers use and map your evidence to them.
- NIST AI Risk Management Framework. A voluntary US framework organized around four functions: Govern, Map, Measure and Manage. The evaluation, monitoring and gating work in Part 5 maps naturally to Measure and Manage.
- Texas Responsible AI Governance Act (TRAIGA). Took effect January 1, 2026, enforced by the Texas Attorney General, and points to the NIST AI RMF as a recognized route to good-faith compliance. Health care providers must also disclose AI use to patients. (McDonald Hopkins; Spencer Fane)
- Sector rules. HIPAA in healthcare; financial regulators’ model risk management expectations in banking; and, for customers operating in Europe, the EU AI Act’s risk-based obligations.
- Security attestations. Customers will often ask for SOC 2 reports or ISO 27001 certification from vendors, and for your system to fit their existing controls.
A practical habit: keep a control map, a simple table linking each requirement the customer cares about to the specific control and evidence in your system. Reviewers love it, and it makes the next review much faster.
6. Getting through the security review
The security review is a negotiation with people who carry the risk if something goes wrong. Treat them as design partners, as described in Part 3. A sequence that works:
- Engage early. Ask the security and compliance teams what they’ll need before you build, not after.
- Send an architecture and data-flow diagram. Show every system, every data movement and every external service, including the model provider.
- Answer the standard questions up front: where data is stored and processed, who can access it, how it’s encrypted, what is logged and for how long, how access is revoked, what happens in an incident.
- Propose a phased scope. “Phase 1 uses de-identified data, read-only, inside your cloud account” is far easier to approve than the full vision.
- Show the controls working. A short demo of the audit log, permission enforcement and approval step does more than ten pages of policy.
- Keep a decision log of what was approved, with which conditions, by whom.
7. How to build these skills
- Draw data-flow diagrams for your own projects. Every arrow is a question a reviewer will ask.
- Read one framework end to end. The NIST AI RMF is free and readable, and it gives you the vocabulary customers use.
- Learn the basics of your target industry’s rules. For healthcare, HIPAA’s privacy and security rules; for finance, model risk management.
- Practice threat modeling on an agent: list its tools, data and permissions, then ask how each could be misused.
- Fill out a real security questionnaire for a personal project. It’s tedious, and it’s exactly what customers will send you.
Let’s talk
What’s the hardest security or compliance review you’ve been through with an AI project, and what finally got it approved? Tell me on LinkedIn or at mohcine@evaltrust.cloud.
The FDE skills series
- Think like a product manager
- From business KPI to F1 score
- The people stack
- Integration and rapid prototyping
- Evaluation, guardrails and observability
- Security, privacy and compliance (this article)
- Domain expertise and scoping
- Communication and ownership
Sources and notes
- Aater Suleman, talk on forward deployed engineering, Dallas, November 5, 2026.
- TRAIGA details from McDonald Hopkins and Spencer Fane.
- HIPAA concepts (business associate agreements, minimum necessary, Safe Harbor and Expert Determination de-identification) are summarized from HHS guidance; NIST AI RMF and the OWASP Top 10 for LLM Applications are referenced at a general level.
- This article is general information, not legal advice.