The customers who most need a forward deployed engineer are the ones with the hardest constraints: banks, hospitals, defense, manufacturers. For them, the AI system's cleverness is irrelevant until it clears security review, and that review is frequently the gate on the whole deployment. An FDE who treats security and compliance as someone else's phase never ships. This page is about the constraint that decides whether your system is allowed to exist.
Why this is the job
Personal-productivity AI ignores all of this — which is exactly why it doesn't count as evidence. Production AI for a real customer lives inside their rules: their data cannot leave their region, their regulator must be able to audit a decision, their security team must sign off before a single user touches it. Clearing that bar is engineering work, and it's work an AI Engineer who has only built demos has never done. The Morgan Stanley engagement shows it plainly: a "zero data retention policy... ensuring Morgan Stanley's proprietary data remains private" was load-bearing to the deal, one of the terms that let it happen at all.
Before reading on: a bank wants an assistant over its internal documents, and its security team asks, "Where does our data go, and can you prove it?" If your answer is "it's sent to the model provider," what have you just lost?
You've likely lost the deal, or at least the next six months, unless you can name exactly where the data flows, what's retained, and how it's isolated. "It goes to the API" is the answer of someone who has never cleared a security review.
What to design for from the first box
Data residency and retention
Know where the data physically lives and for how long. Regulated customers often require that data stay in a region, never be used to train a third party's model, and be retained only as policy allows. Options range from a provider's zero-retention, in-region API tier to fully on-premises or air-gapped deployment with no external calls at all. This choice constrains everything downstream, so settle it first.
Sensitive data handling
Personally identifiable information and other sensitive data need to be minimized, redacted, or tokenized before it reaches a model or a log — and "a log" matters, because an eval trace or a debugging dump is a place sensitive data leaks. Sensitive-information disclosure is a named risk in the OWASP Top 10 for LLM Applications; treat every place data is stored or sent, including your own observability, as in scope.
Access control and isolation
The AI system inherits the customer's permission model — a user must not retrieve, through the assistant, a document they couldn't open directly. That means retrieval and generation have to respect per-user access control, and often that customer data is isolated per tenant. A retrieval system that ignores permissions is a data-leak engine with a friendly interface.
Auditability
In a regulated setting, someone must be able to reconstruct why the system produced a given output: what was retrieved, what prompt was used, who saw it, when. That's the observability trace, kept as an audit record. "The model decided" is not an answer a regulator accepts; the audit trail is what makes an AI decision defensible.
The regimes, and what each forces
The constraints above arrive at a real customer with names attached. Four regimes cover most engagements, and each one converts a design habit this course already teaches into a legal or contractual obligation. The table gives the shape; the paragraphs after it carry the specifics a customer's counsel or security team will expect you to know.
| Regime | What it is | What it forces in an AI deployment |
|---|---|---|
| GDPR | The European Union's General Data Protection Regulation, governing personal data | Lawful basis, data minimization, an erasure path through the index, human intervention on automated decisions, transfer conditions |
| HIPAA | The US Health Insurance Portability and Accountability Act, governing health information | A signed vendor agreement before health data flows, access controls, audit trails |
| SOC 2 | An auditor's attestation report on a service organization's controls | Documented, operating controls: access, change management, monitoring |
| EU AI Act | The European Union's risk-tiered regulation of AI systems | Lifetime event logging and human oversight for high-risk systems, on dated deadlines |
The General Data Protection Regulation (GDPR, EU Regulation 2016/679) requires a lawful basis before personal data is processed at all (Art. 6) and requires the data processed to be "adequate, relevant and limited to what is necessary" (Art. 5) — data minimization, which is the trimming and redaction this page already teaches, restated as law. Two articles bite AI systems specifically. The right to erasure "without undue delay" (Art. 17) reaches into the retrieval index: once personal data is embedded and indexed, honoring an erasure request requires a re-index path, and that path is designed in from day one or it does not exist when the request lands. And Art. 22 grants a right against solely automated decisions with legal or similarly significant effect, including the right to "obtain human intervention" — in some deployments the human-in-the-loop is therefore a legal requirement rather than only a trust practice. High-risk processing takes a data protection impact assessment before it begins (Art. 35), and cross-border transfers are permitted only under conditions (Art. 44) — the article behind the data-residency requirement this page opened with.
The Health Insurance Portability and Accountability Act (HIPAA) governs protected health information (PHI) in the United States. The rule with the most direct consequence for an AI deployment: PHI may go to a vendor only under a Business Associate Agreement (BAA) — "satisfactory assurance … documented through a written contract" (45 CFR 164.502(e)) — so the model provider must sign a BAA before a single patient record touches the API, and a provider that will not sign one is ruled out however good its model. HIPAA's technical safeguards then require access controls limiting systems to granted access rights and audit controls that "record and examine activity in information systems that contain or use electronic protected health information" (45 CFR 164.312). That audit-controls demand is the per-request trace again, this time required by regulation.
SOC 2 (System and Organization Controls 2) is an attestation rather than a law: an auditor examines a service organization's controls against the 2017 Trust Services Criteria, with revised points of focus from 2022, published by the American Institute of Certified Public Accountants (AICPA), across security, availability, processing integrity, confidentiality, and privacy. In practice the auditor wants documented, operating controls in areas like access control, change management, and monitoring. For an AI deployment that maps directly onto machinery this section already teaches: the versioned, gated releases on the deployment page are the change-management evidence, and the monitoring evidence is the observability stack — a SOC 2 audit is in large part a demand that those disciplines exist and leave a paper trail.
The EU AI Act regulates AI systems by risk, in four tiers running from banned practices down to minimal risk. For high-risk systems, two articles read like this course's production pages restated as law: the system must "technically allow for the automatic recording of events (logs) over the lifetime of the system" (Art. 12) and must be designed so "they can be effectively overseen by natural persons" (Art. 14). The timeline is where secondhand material is most often wrong, so state it precisely, as of July 2026: prohibitions have applied since February 2025 and general-purpose-model rules since August 2025; the transparency obligations (Article 50) apply from August 2026; and the high-risk regime was deferred by the amendment agreed in mid-2026 — to December 2027 for stand-alone systems (Annex III) and August 2028 for AI embedded in regulated products (Annex I) — per law-firm trackers of the amendment (Gibson Dunn, Travers Smith). Those are law-firm summaries; check the Official Journal before relying on the dates. Deadlines this fresh are exactly the kind of fact an FDE re-verifies at engagement start, since memory of them goes stale fast.
Read the four rows together and the pattern is plain: the same demands the production section already teaches — logging and traces, human oversight, access control, versioned releases — arrive here as legal requirements. Which regime governs is a property of the customer, and it surfaces in discovery. The FDE's job is to know which one applies to the engagement and design for it from the first box.
Bad / Good / Great — "how do you handle their data?"
Bad — "we send it to the model API; providers are secure." You've outsourced the answer to a security team that will reject it, and shown you don't know where the data goes.
Good — "we use a zero-retention tier, redact PII, and restrict access." Real, correct instincts on the big three — solid mid-level. The gap: nothing on auditability, per-user permissions in retrieval, or the option of on-prem when the customer requires it.
Great — "I'd settle residency and retention first — in-region zero-retention API, or on-prem/air-gapped if they require it — enforce the customer's access model in retrieval so the assistant can't surface what a user couldn't open, redact sensitive data before it hits the model or any log, and keep an audit trail of every retrieval and output so a decision can be reconstructed. And I'd raise all of this in discovery, because it shapes the architecture." You designed for the environment from the first box and made the system auditable — the answer that actually clears review.
What to carry into the interview
When a design prompt names a regulated domain — finance, health, government — do not wait to be asked about security. Surface it early and let it shape the architecture: name where the data lives, how per-user access is enforced, and how a decision is audited. Treating compliance as a first-class design driver from the first box is the difference between a system that demos and one a customer is allowed to deploy.
Related: Guardrails & Safety, Observability & Debugging (the audit trail), and Driving Adoption (why clearing the bar earns trust).
Next: Deployment & MLOps — getting it into the customer's production and keeping it healthy there.NextDeployment & MLOps