How I Built an AI Governance Program on AWS Services — As a Security Engineer

Securing SageMaker, Bedrock, and ML pipelines using EU AI Act risk classification, NIST AI RMF controls, and native AWS security tooling

Stack: AWS SageMaker · Amazon Bedrock · GuardDuty · CloudTrail · AWS Config 
· CloudWatch · Security Hub · IAM · VPC · Amazon Macie

Frameworks: EU AI Act (2024/1689) · NIST AI RMF 1.0 · GDPR

Audience: SOC Analysts · Cloud Security Engineers · GRC Practitioners

Why a Secuirty Engineer Is Writing About AI Governance

When most people hear “AI governance,” they picture compliance teams writing policy documents nobody reads.

That’s not what this is.

I’m a Security Engineer. I monitor alerts, triage incidents, investigate anomalies. And I noticed a dangerous blind spot: the AI systems running in our AWS environment — processing credit decisions, flagging fraud, screening candidates — were completely invisible to our security monitoring stack.

A SageMaker endpoint making 50,000 credit scoring decisions per day is a critical asset. If it gets poisoned, drifts, or gets abused, the impact isn’t just a security incident. It’s a regulatory event. It’s customer harm. It’s potentially an EU AI Act violation.

Nobody on the security team was watching it.

This article is how I fixed that — by combining three things that are almost never discussed together:

• EU AI Act — to classify which AI systems carry the most regulatory risk
• NIST AI RMF— to build the governance and control structure around each system
• AWS native security tools — to actually implement and monitor those controls

The Company: FinNova Technologies

FinNova is a fictional but realistic UK/EU fintech firm. It processes over 50,000 loan applications annually and runs six AI systems across its business:

╔══════════════════════════════════════════════════════════════════════╗
║              FINNOVA AI SYSTEMS — FULL LANDSCAPE                     ║
╠══════════════════════════════════════════════════════════════════════╣
║                                                                      ║
║  SYS-001  CreditScore AI    →  Automated loan approval/rejection     ║
║  SYS-002  FraudGuard Pro    →  Real-time transaction fraud blocking  ║
║  SYS-003  NovaChatBot       →  Customer service chatbot (GPT-4)      ║
║  SYS-004  PersonaTarget     →  Marketing personalisation engine      ║
║  SYS-005  RegWatch AI       →  Regulatory change monitoring          ║
║  SYS-006  HRScreener        →  CV screening and candidate ranking    ║
║                                                                      ║
║  All six systems run on AWS.                                         ║
║  Three are HIGH RISK under the EU AI Act.                            ║
║  Zero were visible in the SOC dashboard before this project.         ║
╚══════════════════════════════════════════════════════════════════════╝

The starting point for any governance program is knowing what you’re governing. Let’s start there.

Part 1: AI Security vs AI Governance — Clearing Up the Confusion

Before anything else, let me separate two things that people constantly conflate:

┌─────────────────────────────────────────────────────────────────────┐
│               AI SECURITY  vs  AI GOVERNANCE                        │
├───────────────────────────────┬─────────────────────────────────────┤
│       AI SECURITY             │         AI GOVERNANCE               │
│    (Traditional SOC)          │      (GRC + SOC combined)           │
├───────────────────────────────┼─────────────────────────────────────┤
│ • Protect the infrastructure  │ • Classify AI risk (EU AI Act)      │
│   running AI systems          │ • Assign accountability + owners    │
│ • Detect training data theft  │ • Ensure fairness + transparency    │
│ • Monitor for API abuse       │ • Build human oversight mechanisms  │
│ • Prevent model poisoning     │ • Comply with Annex III obligations │
│ • IAM hardening + VPC isol.   │ • Post-market monitoring (Art. 61)  │
│ • Respond to ML incidents     │ • Audit trails for regulators       │
│ • Detect adversarial inputs   │ • Bias monitoring + redress         │
└───────────────────────────────┴─────────────────────────────────────┘

Most AWS security articles cover the left column only. The problem: if you only secure AI infrastructure without understanding why that infrastructure is regulated, you’re building controls without knowing what you’re protecting against.

A Security Engineer who understands both columns is genuinely rare. That’s what this article builds toward.

Part 2: EU AI Act — Classify Risk Before You Build Controls

The EU AI Act (Regulation 2024/1689) uses a four-tier risk pyramid. The tier determines the obligations. Obligations determine the controls you need to implement on AWS.

                    ╔═══════════════════════════╗
                    ║      PROHIBITED AI        ║
                    ║                           ║
                    ║  Social scoring citizens  ║
                    ║  Real-time biometrics     ║
                    ║  in public spaces         ║
                    ║  Subliminal manipulation  ║
                    ╠═══════════════════════════╣
                    ║       HIGH RISK           ║
                    ║    (Annex III systems)    ║
                    ║                           ║
                    ║  Credit scoring  ──SYS-001║
                    ║  Fraud detection ──SYS-002║
                    ║  CV screening    ──SYS-006║
                    ║  Biometric ID             ║
                    ║  Law enforcement AI       ║
                    ╠═══════════════════════════╣
                    ║     LIMITED RISK          ║
                    ║  (Transparency only)      ║
                    ║                           ║
                    ║  Chatbots        ──SYS-003║
                    ║  AI-generated content     ║
                    ╠═══════════════════════════╣
                    ║     MINIMAL RISK          ║
                    ║   (Voluntary CoC)         ║
                    ║                           ║
                    ║  Marketing AI    ──SYS-004║
                    ║  Reg monitoring  ──SYS-005║
                    ║  Spam filters             ║
                    ╚═══════════════════════════╝

Why this matters for AWS security work:

The risk tier determines which controls are legally mandatory, not just best practice. A HIGH-RISK system under Annex III requires conformity assessment, human oversight mechanisms, logging, accuracy monitoring, and post-market surveillance — all of which need to be implemented at the AWS infrastructure level.

FinNova Classification Breakdown

SYS-001 CreditScore AI → HIGH RISK

Legal basis: Annex III §5(b) — “AI for creditworthiness assessment.”

This system automatically approves or rejects loans. Denied access to credit is a fundamental rights issue. CloudTrail logging, CloudWatch drift monitoring, and human review queues are not optional — they are Article 14 and Article 15 requirements.

SYS-002 FraudGuard Pro → HIGH RISK

Legal basis: Annex III §5(b) — “AI affecting access to financial services.”

Critical point: FinNova uses a vendor product (Featurespace ARIC). Under the EU AI Act, the deployer carries obligations regardless. “We use a third-party tool” is not a compliance defence.

SYS-003 NovaChatBot → LIMITED RISK

Legal basis: Article 50 — transparency obligations.

Single obligation: users must know they are talking to an AI. No Annex III match. No conformity assessment required.

SYS-004 PersonaTarget → MINIMAL RISK

Recommends products. Does not deny access. No Annex III match. GDPR Art. 22 profiling rules apply separately.

SYS-005 RegWatch AI → MINIMAL RISK

Advisory only — every output reviewed by a human. No personal data. No binding decisions. Minimal risk despite high-stakes domain.

SYS-006 HRScreener → HIGH RISK

Legal basis: Annex III §4 — “AI for recruitment, CV sorting, candidate evaluation.”

This is the one most organization miss. Employment access is a fundamental right. CV screening tools are explicitly listed in Annex III. If you have an HR screening tool and haven’t done a bias audit, you are non-compliant right now.

Part 3: NIST AI RMF — The Control Structure

The EU AI Act tells you what is required. The NIST AI Risk Management Framework (2023) tells you how to build the governance structure to meet those requirements.

┌─────────────────────────────────────────────────────────────────────┐
│                      NIST AI RMF 1.0                                │
│                                                                     │
│   ┌──────────────┐                                                  │
│   │   GOVERN     │  Underpins everything. Policies, accountability, │
│   │              │  risk appetite, roles, ethics committee.         │
│   └──────┬───────┘                                                  │
│          │ feeds into                                               │
│          ▼                                                          │
│   ┌──────────────┐                                                  │
│   │    MAP       │  Understand context. Who are stakeholders?       │
│   │              │  What risks exist? What's the intended use?      │
│   └──────┬───────┘                                                  │
│          │ feeds into                                               │
│          ▼                                                          │
│   ┌──────────────┐                                                  │
│   │   MEASURE    │  Quantify risk. KPIs, fairness metrics,          │
│   │              │  accuracy benchmarks, drift detection.           │
│   └──────┬───────┘                                                  │
│          │ feeds into                                               │
│          ▼                                                          │
│   ┌──────────────┐                                                  │
│   │   MANAGE     │  Respond. Escalate. Remediate. Document.         │
│   │              │  Incident playbooks. Rollback capability.        │
│   └──────┬───────┘                                                  │
│          │ feeds back into                                          │
│          └──────────────────────────────────► GOVERN                │
│                                                                     │
│  It is cyclical, not linear. Each incident informs policy.          │
└─────────────────────────────────────────────────────────────────────┘

Proportionality principle — not every system needs everything:

Risk Tier      GOVERN   MAP    MEASURE   MANAGE
─────────────────────────────────────────────────
HIGH RISK       ████    ████    ████      ████    ← All four, fully active
LIMITED RISK    ████    ████    ██░░      ██░░    ← Policy + context + basic monitoring
MINIMAL RISK    ████    ██░░    ░░░░      ░░░░    ← Policy + risk ID only

Applying the same controls to all six systems wastes resources and misses the point. The HRScreener needs quarterly bias audits. The RegWatch AI does not.

NIST RMF Applied to CreditScore AI (SYS-001)

┌─────────────────────────────────────────────────────────────────────┐
│  SYSTEM: CreditScore AI (SYS-001) — HIGH RISK                       │
├──────────┬──────────────────────────────────────────────────────────┤
│ GOVERN   │ AI Governance Policy v2.0 active                         │
│          │ Executive sponsor: Chief Risk Officer                    │
│          │ Ethics Committee quarterly review                        │
│          │ Risk appetite: FP rate < 0.5%, FN rate < 2%              │
│          │ AWS implementation: IAM policies, SCPs, Config rules     │
├──────────┼──────────────────────────────────────────────────────────┤
│ MAP      │ Mapped to retail lending process                         │
│          │ Stakeholders: customers, credit officers, FCA            │
│          │ Risks identified: age bias, postcode proxy, drift        │
│          │ AWS implementation: CloudTrail tagging, resource groups  │
├──────────┼──────────────────────────────────────────────────────────┤
│ MEASURE  │ Monthly accuracy KPIs tracked                            │
│          │ Demographic parity metrics (equal opportunity)           │
│          │ SHAP drift detection (feature weight shifts)             │
│          │ AWS implementation: CloudWatch custom metrics, alarms    │
│          │ SageMaker Model Monitor for data + model drift           │
├──────────┼──────────────────────────────────────────────────────────┤
│ MANAGE   │ Human review for borderline scores (580–650 band)        │
│          │ Retraining triggered if accuracy drops > 2%              │
│          │ Rollback to last verified model version                  │
│          │ AWS implementation: Step Functions, SageMaker Pipelines  │
│          │ Incident playbook: model poisoning response              │
└──────────┴──────────────────────────────────────────────────────────┘

Part 4: The AWS Architecture — SOC View

Here is what FinNova’s AI infrastructure looks like from a security monitoring perspective:

╔══════════════════════════════════════════════════════════════════════╗
║              FINNOVA AWS AI ARCHITECTURE — SOC VIEW                  ║
╠══════════════════════════════════════════════════════════════════════╣
║                                                                      ║
║  INTERNET EDGE                                                       ║
║  ──────────────                                                      ║
║  Customer Requests ──► AWS WAF ──► API Gateway                       ║
║                        (rate limit,  (auth, routing,                 ║
║                         OWASP rules)  logging)                       ║
║                                           │                          ║
║  ═══════════════════════════════════════════════════════════════     ║
║  PRIVATE VPC (eu-west-1)                  │                          ║
║  ──────────────────────                   ▼                          ║
║                              ┌────────────────────────┐              ║
║                              │  SageMaker Endpoints   │              ║
║                              │  (Private Subnets only)│              ║
║                              │  SYS-001 CreditScore   │              ║
║                              │  SYS-002 FraudGuard    │              ║
║                              └────────────┬───────────┘              ║
║                                           │                          ║
║                              ┌────────────▼───────────┐              ║
║                              │  S3 ML Training Data   │              ║
║                              │  (KMS CMK encrypted)   │              ║
║                              │  (Object Lock enabled) │              ║
║                              └────────────────────────┘              ║
║                                                                      ║
║  ═══════════════════════════════════════════════════════════════     ║
║  MONITORING & GOVERNANCE LAYER                                       ║
║  ─────────────────────────────                                       ║
║  CloudTrail ──► CloudWatch Logs ──► Security Hub ──► SOC Dashboard   ║
║  GuardDuty  ──► SNS/EventBridge ──► PagerDuty   ──► SOC Analyst      ║
║  AWS Config ──► Compliance Hub  ──► Findings    ──► Remediation      ║
║  Macie      ──► DLP Findings    ──► DPO Alerts  ──► GDPR Response    ║
║  SageMaker  ──► Model Monitor   ──► Drift Alerts──► ML Team          ║
║  Model Monitor                                                       ║
╚══════════════════════════════════════════════════════════════════════╝

Each layer maps to specific EU AI Act and NIST RMF requirements. Let’s go through every control.

Part 5: AWS Config — Continuous Compliance

AWS Config gives continuous visibility into whether AI resources are configured correctly. These are the rules that matter for AI governance specifically:

┌─────────────────────────────────────────────────────────────────────┐
│              AWS CONFIG RULES — AI GOVERNANCE MAPPING               │
├──────────────────────────────────┬────────────────┬─────────────────┤
│  Config Rule                     │ EU AI Act Ref  │ Risk if Failed  │
├──────────────────────────────────┼────────────────┼─────────────────┤
│ s3-bucket-server-side-           │ Art. 10        │ Training data   │
│ encryption-enabled               │ Data governance│ breach, GDPR    │
├──────────────────────────────────┼────────────────┼─────────────────┤
│ sagemaker-notebook-no-direct-    │ Art. 15        │ Model theft,    │
│ internet-access                  │ Cybersecurity  │ data exfil      │
├──────────────────────────────────┼────────────────┼─────────────────┤
│ sagemaker-endpoint-config-       │ Art. 10 + 15   │ PII exposure    │
│ kms-key-configured               │ Data + Cyber   │ during scoring  │
├──────────────────────────────────┼────────────────┼─────────────────┤
│ iam-user-no-policies-check       │ Art. 14        │ Over-privileged │
│                                  │ Human oversight│ ML engineers    │
├──────────────────────────────────┼────────────────┼─────────────────┤
│ guardduty-enabled-centralized    │ Art. 15        │ Blind spots in  │
│                                  │ Cybersecurity  │ AI workloads    │
├──────────────────────────────────┼────────────────┼─────────────────┤
│ vpc-sg-open-only-to-             │ Art. 15        │ Publicly        │
│ authorized-ports                 │ Cybersecurity  │ exposed models  │
└──────────────────────────────────┴────────────────┴─────────────────┘

Enable Config in every region where AI workloads run. SageMaker training jobs frequently spin up in us-east-1 even when production is in eu-west-1. A Config rule that only covers one region is a governance gap.

Trigger manual evaluation after adding rules:

aws configservice start-config-rules-evaluation \
  --config-rule-names \
  s3-bucket-server-side-encryption-enabled \
  sagemaker-notebook-no-direct-internet-access \
  sagemaker-endpoint-config-kms-key-configured \
  guardduty-enabled-centralized

Part 6: CloudTrail — What to Actually Watch

CloudTrail logs every API call. A busy SageMaker environment generates thousands per hour. Knowing which events actually matter is the difference between a SOC analyst and someone just watching a scrolling log.

╔═════════════════════════════════════════════════════════════════════╗
║           CLOUDTRAIL — AI GOVERNANCE HIGH-SIGNAL EVENTS             ║
╠══════════════════╦══════════════════════════════╦═══════════════════╣
║  Event           ║  Why It Matters              ║  SOC Response     ║
╠══════════════════╬══════════════════════════════╬═══════════════════╣
║ CreateModel      ║ New model deployed —         ║ Verify approved   ║
║                  ║ who approved this?           ║ change ticket     ║
╠══════════════════╬══════════════════════════════╬═══════════════════╣
║ DeleteModel      ║ Outside maintenance window   ║ URGENT: possible  ║
║                  ║ is a red flag                ║ evidence deletion ║
╠══════════════════╬══════════════════════════════╬═══════════════════╣
║ UpdateEndpoint   ║ Config change mid-production ║ Check who + why   ║
╠══════════════════╬══════════════════════════════╬═══════════════════╣
║ InvokeEndpoint   ║ Unknown IP or volume spike   ║ Check allowlist   ║
║                  ║                              ║ + rate limits     ║
╠══════════════════╬══════════════════════════════╬═══════════════════╣
║ PutBucketPolicy  ║ On ML training data bucket   ║ Could expose      ║
║                  ║                              ║ training data     ║
╠══════════════════╬══════════════════════════════╬═══════════════════╣
║ GetObject (bulk) ║ Mass download of training    ║ Possible exfil —  ║
║                  ║ data by unusual principal    ║ investigate now   ║
╠══════════════════╬══════════════════════════════╬═══════════════════╣
║ CreateTrainingJob║ Unexpected retraining — was  ║ Verify scheduled  ║
║                  ║ this authorised?             ║ vs unscheduled    ║
╠══════════════════╬══════════════════════════════╬═══════════════════╣
║ AssumRole (ML    ║ Role assumption by unusual   ║ Credential        ║
║ engineer role)   ║ principal or off-hours       ║ compromise risk   ║
╚══════════════════╩══════════════════════════════╩═══════════════════╝

Query SageMaker activity via CLI:

aws cloudtrail lookup-events \
  --lookup-attributes \
    AttributeKey=EventSource,AttributeValue=sagemaker.amazonaws.com \
  --start-time 2026-06-21T00:00:00Z \
  --max-results 50 \
  --query 'Events[*].[EventTime,EventName,Username,SourceIPAddress]' \
  --output table

The question to ask about every unexpected event: Was this authorised, expected, and documented? In the EU AI Act context — is it logged in the system’s audit trail (Art. 12)?

Part 7: GuardDuty — AI Threat Detection

GuardDuty uses ML to detect threats, which makes it well-suited to spotting anomalies in ML workloads. These are the finding types most relevant to AI systems:

┌─────────────────────────────────────────────────────────────────────┐
│         GUARDDUTY FINDINGS — AI WORKLOAD RELEVANCE                  │
├──────────────────────────────────┬──────────────────────────────────┤
│  Finding                         │  AI Governance Relevance         │
├──────────────────────────────────┼──────────────────────────────────┤
│ Exfiltration:S3/ObjectRead.      │ Training data theft              │
│ Unusual                          │ → GDPR 72hr clock starts         │
│                                  │ → EU AI Act Art. 10 breach       │
├──────────────────────────────────┼──────────────────────────────────┤
│ IAM/AnomalousBehavior            │ Compromised ML engineer          │
│                                  │ → Model poisoning risk           │
│                                  │ → Art. 15 cybersecurity breach   │
├──────────────────────────────────┼──────────────────────────────────┤
│ UnauthorizedAccess:EC2/          │ SageMaker notebook accessed      │
│ TorIPCaller                      │ from anonymised network          │
│                                  │ → IP theft / espionage risk      │
├──────────────────────────────────┼──────────────────────────────────┤
│ Discovery:S3/TorIPCaller         │ Reconnaissance on ML data        │
│                                  │ → Pre-exfiltration behaviour     │
├──────────────────────────────────┼──────────────────────────────────┤
│ S3/MaliciousIPCaller             │ Known bad actor accessing        │
│                                  │ training data bucket             │
├──────────────────────────────────┼──────────────────────────────────┤
│ Execution:Runtime/               │ Malicious code running inside    │
│ MaliciousFile                    │ SageMaker notebook environment   │
└──────────────────────────────────┴──────────────────────────────────┘

Route GuardDuty findings to SNS → PagerDuty. Any finding touching an ML S3 bucket or SageMaker resource should be treated as P1 — not P3. These are not generic cloud assets.

Part 8: IAM Least Privilege for AI Systems

The tension in ML environments: data scientists need broad permissions to experiment. Production endpoints need the opposite.

The rule: Experiment accounts can be permissive. Production AI endpoints cannot.

IAM policy for CreditScore AI production endpoint — nothing more, nothing less:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CreditScoreProductionInferenceOnly",
      "Effect": "Allow",
      "Action": [
        "sagemaker:InvokeEndpoint"
      ],
      "Resource": [
        "arn:aws:sagemaker:eu-west-1:123456789012:endpoint/creditscore-prod"
      ],
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "eu-west-1"
        },
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        },
        "IpAddress": {
          "aws:SourceIp": ["10.0.0.0/8"]
        }
      }
    }
  ]
}

Three conditions beyond the basic allow:

• Region lock — requests outside eu-west-1 are denied automatically
• MFA required — no single-factor access to a HIGH-RISK AI system
• IP allowlist — only internal network can invoke the endpoint

Quarterly IAM audit checklist for HIGH-RISK AI systems:

□ Which roles have sagemaker:* wildcard access?
□ Are ML engineers using production credentials for experiments?
□ Do service accounts have permissions beyond their function?
□ Are any IAM users (not roles) invoking AI endpoints?
□ Are all access key ages within policy?
□ Does the conformity assessment reference current IAM policies?

Part 9: CloudWatch — Monitoring Model Behaviour, Not Just Infrastructure

Standard CloudWatch tracks CPU, latency, error rates. For AI governance, we also need to track model behaviour— because a drifting model is both a security risk and an EU AI Act compliance issue.

┌─────────────────────────────────────────────────────────────────────┐
│         CLOUDWATCH METRICS — AI GOVERNANCE DASHBOARD                │
├─────────────────────────────┬──────────────┬────────────────────────┤
│  Metric                     │  Target      │  Alarm / EU AI Act Ref │
├─────────────────────────────┼──────────────┼────────────────────────┤
│  Model Accuracy             │  > 95%       │  Alert < 93%           │
│  (CreditScore AI)           │              │  Art. 15 — accuracy    │
├─────────────────────────────┼──────────────┼────────────────────────┤
│  Endpoint Latency           │  < 200ms     │  Alert > 500ms         │
│                             │              │  SLA breach            │
├─────────────────────────────┼──────────────┼────────────────────────┤
│  4xx Error Rate             │  < 0.5%      │  Alert > 1%            │
│  (invalid / adversarial)    │              │  Possible attack       │
├─────────────────────────────┼──────────────┼────────────────────────┤
│  Invocation Volume          │  Baseline    │  Alert > 3x baseline   │
│                             │  ± 20%       │  API abuse / scraping  │
├─────────────────────────────┼──────────────┼────────────────────────┤
│  SHAP Feature Weight Drift  │  Stable      │  Alert > 15% shift     │
│  (CreditScore AI)           │              │  Art. 61 — post-market │
│                             │              │  monitoring            │
├─────────────────────────────┼──────────────┼────────────────────────┤
│  False Positive Rate        │  < 0.1%      │  CRITICAL > 0.5%       │
│  (FraudGuard Pro)           │              │  Customer harm + Art.15│
├─────────────────────────────┼──────────────┼────────────────────────┤
│  Disparate Impact Ratio     │  > 0.8       │  SUSPEND if < 0.8      │
│  (HRScreener)               │  (EEOC 4/5)  │  Art. 10 + Annex III §4│
└─────────────────────────────┴──────────────┴────────────────────────┘

Why the SHAP drift metric matters legally: Under EU AI Act Article 61, HIGH RISK systems must be monitored for changes that could affect fundamental rights. If a credit scoring model’s feature weights shift significantly month-on-month, it may no longer be making decisions on the grounds stated in its conformity assessment. That is a regulatory event — not just a performance issue.

Part 10: S3 Encryption for ML Training Data

Training data is the most regulated asset in an AI system. EU AI Act Article 10 requires data governance documentation for HIGH RISK systems. GDPR adds additional requirements when training data contains personal information.

S3 bucket policy — two mandatory controls:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnencryptedUploads",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::finnova-ml-training-data/*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-server-side-encryption": "aws:kms"
        }
      }
    },
    {
      "Sid": "DenyHTTPAccess",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::finnova-ml-training-data",
        "arn:aws:s3:::finnova-ml-training-data/*"
      ],
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"
        }
      }
    }
  ]
}

Also enable — non-negotiable for HIGH RISK AI systems:

• S3 Block Public Access (all four settings)
• S3 Object Lock (COMPLIANCE mode) — prevents log and training data tampering, required for Art. 12 audit trail integrity
• Amazon Macie — automatically detects if PII has leaked into training data

Part 11: VPC Isolation for SageMaker Endpoints

A SageMaker endpoint processing credit decisions should never be publicly reachable. This is not just a security best practice — it is an EU AI Act Article 15 (cybersecurity) requirement.

CORRECT — Private Endpoint Architecture
──────────────────────────────────────────────────────────────────
  App Tier ──► API Gateway ──► VPC Endpoint ──► SageMaker
  (Internal)    (auth/WAF)     (PrivateLink)    (Private Subnet)
                                                      │
                                               No Internet Gateway
                                               No NAT Gateway
                                               Port 443 only
                                               Security Group:
                                               allow app tier only

WRONG — Public Endpoint Architecture
──────────────────────────────────────────────────────────────────
  Internet ─────────────────────────────────► SageMaker
                                               (Publicly Accessible)
  This is an EU AI Act Art. 15 violation.
  This has happened in production environments.

Create the VPC endpoint:

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-YOUR-VPC-ID \
  --service-name com.amazonaws.eu-west-1.sagemaker.runtime \
  --vpc-endpoint-type Interface \
  --subnet-ids subnet-PRIVATE-1 subnet-PRIVATE-2 \
  --security-group-ids sg-YOUR-SG-ID \
  --private-dns-enabled

The private-dns-enabled flag ensures all sagemaker.runtime API calls within the VPC resolve to the private endpoint automatically, without any code changes.

Part 12: Security Hub — Single Pane for AI Compliance

Security Hub aggregates findings from Config, GuardDuty, Inspector, and Macie. For AI governance, create this custom insight:

Insight: “AI Systems — Critical Compliance Findings”

Filter:
  (ProductName = "Config" OR ProductName = "GuardDuty" OR ProductName = "Macie")
  AND (SeverityLabel = "CRITICAL" OR SeverityLabel = "HIGH")
  AND (ResourceId CONTAINS "sagemaker" OR ResourceId CONTAINS "finnova-ml")
Group by: ResourceId

For HIGH-RISK systems — review this insight daily. Not weekly.

Enable: AWS Foundational Security Best Practices standard. It includes SageMaker, S3, IAM, and VPC controls that map directly to EU AI Act Article 15.

Part 13: SIEM Alert Rules for AI Workloads

These are the six alert rules I would write in any SIEM covering FinNova’s AI environment:

╔═════════════════════════════════════════════════════════════════════╗
║                  AI-SPECIFIC SIEM ALERT RULES                       ║
╠══════════╦═════════════════════════════════╦══════════╦═════════════╣
║  Rule ID ║  Detection Logic                ║ Severity ║  Response   ║
╠══════════╬═════════════════════════════════╬══════════╬═════════════╣
║  AI-001  ║ CreditScore model accuracy      ║  HIGH    ║ Notify ML   ║
║          ║ drops > 5% from 30-day baseline ║          ║ team; review║
║          ║ in CloudWatch                   ║          ║ model vers. ║
╠══════════╬═════════════════════════════════╬══════════╬═════════════╣
║  AI-002  ║ FraudGuard false positive       ║ CRITICAL ║ Escalate to ║
║          ║ rate spikes > 1% in 1-hr window ║          ║ fraud team; ║
║          ║                                 ║          ║ manual mode ║
╠══════════╬═════════════════════════════════╬══════════╬═════════════╣
║  AI-003  ║ NovaChatBot prompt injection    ║  MEDIUM  ║ 100% human  ║
║          ║ pattern detected OR hallucin.   ║          ║ review; log ║
║          ║ rate > 5% from Azure Content    ║          ║ for red team║
║          ║ Safety API                      ║          ║             ║
╠══════════╬═════════════════════════════════╬══════════╬═════════════╣
║  AI-004  ║ PersonaTarget off-hours data    ║  MEDIUM  ║ Investigate;║
║          ║ access OR > 10x normal volume   ║          ║ notify DPO  ║
║          ║ on ML S3 bucket                 ║          ║ if PII      ║
╠══════════╬═════════════════════════════════╬══════════╬═════════════╣
║  AI-005  ║ RegWatch vendor (Ascent)        ║   LOW    ║ Notify CCO; ║
║          ║ API unavailable > 4 hrs         ║          ║ manual reg  ║
║          ║ during business hours           ║          ║ monitoring  ║
╠══════════╬═════════════════════════════════╬══════════╬═════════════╣
║  AI-006  ║ HRScreener rejection rate       ║  HIGH    ║ SUSPEND     ║
║          ║ > 30% variance from baseline    ║          ║ screening;  ║
║          ║ for any demographic group       ║          ║ bias audit  ║
╚══════════╩═════════════════════════════════╩══════════╩═════════════╝

Part 14: Incident Response Playbooks

Playbook 1: Model Poisoning via Compromised ML Pipeline

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
INCIDENT TYPE: Model Poisoning — CreditScore AI (SYS-001)
SEVERITY: CRITICAL
REGULATORY IMPACT: EU AI Act Art. 15 + Art. 61 | FCA notification
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

DETECTION SIGNALS
  GuardDuty  : IAM/AnomalousBehavior on ML engineer role
  CloudTrail : Unexpected PutObject to finnova-ml-training-data
  CloudWatch : Model accuracy drops > 5% within 24 hours
  SIEM       : Alert AI-001 fires

STEP 1 — ISOLATE (T+0 to T+15 min)
  □ Revoke compromised IAM session tokens immediately:
      aws iam delete-access-key \
        --user-name ml-engineer-01 \
        --access-key-id AKIAIOSFODNN7EXAMPLE
  □ Remove SageMaker endpoint from API Gateway target group
  □ Enable S3 Block Public Access on training bucket
  □ Preserve ALL CloudTrail logs — disable log rotation NOW
  □ Snapshot current SageMaker endpoint config

STEP 2 — ASSESS (T+15 to T+60 min)
  □ Timeline: when did anomalous S3 writes begin?
  □ Which objects in the training bucket were modified?
  □ Has a retraining job run since the compromise?
  □ Which model version is currently serving production traffic?
  □ How many credit decisions were made since contamination?

STEP 3 — NOTIFY (T+30 min)
  □ ML Engineering Lead (technical owner)
  □ Head of Credit Risk (business owner)
  □ CRO + AI Governance Board if > 500 decisions affected
  □ DPO — GDPR 72-hour clock starts if personal data accessed
  □ FCA — if production credit decisions were materially affected

STEP 4 — REMEDIATE
  □ Roll back to last verified-clean model version
  □ Restore training data from S3 Object Lock backup
  □ Verify integrity with checksums before retraining
  □ Retrain only from verified clean dataset
  □ Independent validation before production reactivation
  □ Gradual rollout: 5% → 25% → 100% traffic with monitoring

STEP 5 — POST-INCIDENT (within 72 hours)
  □ Root cause analysis documented
  □ Update IAM policies restricting training pipeline access
  □ Enable S3 Object Lock on ALL ML training buckets
  □ Entry in EU AI Act post-market monitoring register (Art. 61)
  □ Legal review: FCA regulatory disclosure required?
  □ Update this playbook with lessons learned
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Playbook 2: Training Data Exfiltration from S3

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
INCIDENT TYPE: ML Training Data Exfiltration
SEVERITY: CRITICAL
REGULATORY IMPACT: GDPR Art. 33 (72 hrs) | EU AI Act Art. 10 | FCA
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

DETECTION SIGNALS
  GuardDuty  : Exfiltration:S3/ObjectRead.Unusual
  Macie      : Sensitive data finding on finnova-ml-training-data
  CloudTrail : Bulk GetObject by unknown or unusual principal
  SIEM       : AI-004 fires with > 10x volume anomaly

STEP 1 — CONTAIN (T+0 to T+20 min)
  □ Identify the IAM principal making requests (CloudTrail)
  □ Disable or quarantine the role/user immediately
  □ Enable S3 Block Public Access on all ML buckets
  □ Rotate any exposed access keys
  □ Revoke all active sessions for the compromised principal:
      aws sts get-caller-identity  # Confirm current identity
      aws iam attach-user-policy \
        --user-name COMPROMISED_USER \
        --policy-arn arn:aws:iam::aws:policy/AWSDenyAll

STEP 2 — SCOPE THE BREACH (T+20 to T+90 min)
  □ How many S3 objects were accessed? (S3 Server Access Logs)
  □ What data was in those objects?
      → Personal data (names, financials)?  → GDPR clock: T+0
      → Training labels + feature data?     → Model integrity risk
      → Feature engineering scripts/code?  → IP theft
  □ Was data downloaded or only read?
  □ Were other ML buckets accessed in same session?

STEP 3 — NOTIFY (T+30 min if personal data confirmed)
  □ DPO — immediately on personal data confirmation
  □ ICO (UK) or relevant DPA — within 72 hours (GDPR Art. 33)
  □ Affected customers — if high risk to their rights (Art. 34)
  □ FCA — if training data integrity affects live model decisions
  □ Legal counsel — for regulatory disclosure strategy

STEP 4 — REMEDIATE
  □ Rotate KMS CMK keys for all affected buckets
  □ Re-encrypt all objects under new key
  □ Enable S3 Object Lock on all training data going forward
  □ Add Macie sensitive data classification to all ML buckets
  □ Audit all other ML buckets for identical misconfigurations
  □ Review and tighten S3 bucket policies across environment
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Playbook 3: Adversarial Input Attack on FraudGuard Pro

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
INCIDENT TYPE: Adversarial Input Attack — FraudGuard Pro (SYS-002)
SEVERITY: HIGH
REGULATORY IMPACT: EU AI Act Art. 15 (robustness) | PSD2 | FCA
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

DETECTION SIGNALS
  CloudWatch : Fraud detection rate drops significantly
               OR false positive rate spikes > 1%
  CloudTrail : Unusual InvokeEndpoint pattern (high frequency,
               structured payloads)
  WAF Logs   : Anomalous payload patterns on API Gateway
  SIEM       : AI-002 fires

STEP 1 — ASSESS (T+0 to T+30 min)
  □ Is fraud bypassing the model (evasion attack)?
      → Check: are flagged transactions decreasing while
        fraud losses are increasing?
  □ Is model causing excessive false positives (poisoned inputs)?
      → Check: customer complaint rate + block volume
  □ Identify attack vector: API abuse, crafted inputs, replay?

STEP 2 — CONTAIN
  □ Temporarily lower fraud score threshold (reduce evasion risk)
  □ Enable enhanced WAF rules on API Gateway
  □ Preserve suspicious payloads for analysis (do not discard)
  □ Enable manual review for all HIGH value transactions

STEP 3 — NOTIFY
  □ Featurespace (vendor) — contractual SLA response required
  □ Chief Risk Officer
  □ Fraud Analytics Team
  □ FCA — if material fraud losses or customer impact

STEP 4 — REMEDIATE
  □ Update API Gateway WAF rules to filter attack patterns
  □ Work with Featurespace on adversarial training examples
  □ Retrain model with identified adversarial patterns
  □ Re-test model robustness before restoring normal thresholds
  □ Add attack pattern to monthly red team test library

STEP 5 — POST-INCIDENT
  □ Document: EU AI Act Art. 15 requires robustness testing
  □ Schedule quarterly adversarial robustness testing
  □ Review vendor SLA — was contractual response time met?
  □ Update threat model for FraudGuard Pro
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Part 15: The Master Mapping — EU AI Act + NIST RMF + AWS Controls

This is the table that ties everything together:

┌─────────────────────────────────────────────────────────────────────┐
│     EU AI ACT  →  NIST AI RMF  →  AWS IMPLEMENTATION                │
├──────────────────┬────────────────┬─────────────────────────────────┤
│  EU AI Act       │  NIST RMF      │  AWS Control                    │
│  Requirement     │  Function      │                                 │
├──────────────────┼────────────────┼─────────────────────────────────┤
│  Art. 9          │  GOVERN        │  AWS Config rules               │
│  Risk mgmt system│                │  Service Control Policies (SCPs)│
│                  │                │  IAM Permission Boundaries      │
├──────────────────┼────────────────┼─────────────────────────────────┤
│  Art. 10         │  GOVERN + MAP  │  S3 KMS encryption              │
│  Data governance │                │  Amazon Macie                   │
│                  │                │  S3 Object Lock                 │
│                  │                │  VPC data classification tags   │
├──────────────────┼────────────────┼─────────────────────────────────┤
│  Art. 11         │  MAP           │  AWS Systems Manager            │
│  Technical docs  │                │  Resource Groups + Tags         │
│                  │                │  inventory.json in S3           │
├──────────────────┼────────────────┼─────────────────────────────────┤
│  Art. 12         │  MEASURE       │  CloudTrail (immutable logs)    │
│  Record-keeping  │                │  CloudWatch Logs                │
│                  │                │  S3 Object Lock audit trail     │
├──────────────────┼────────────────┼─────────────────────────────────┤
│  Art. 14         │  MANAGE        │  Manual review queues           │
│  Human oversight │                │  Step Functions escalation      │
│                  │                │  API Gateway human handoff      │
├──────────────────┼────────────────┼─────────────────────────────────┤
│  Art. 15         │  MEASURE +     │  VPC isolation                  │
│  Accuracy,       │  MANAGE        │  GuardDuty + WAF                │
│  robustness,     │                │  IAM least privilege            │
│  cybersecurity   │                │  CloudWatch accuracy alarms     │
├──────────────────┼────────────────┼─────────────────────────────────┤
│  Art. 50         │  GOVERN        │  API Gateway response headers   │
│  Transparency    │                │  Chatbot disclosure banner      │
│  (chatbots)      │                │  Lambda injection (AI label)    │
├──────────────────┼────────────────┼─────────────────────────────────┤
│  Art. 61         │  MEASURE +     │  SageMaker Model Monitor        │
│  Post-market     │  MANAGE        │  CloudWatch SHAP drift alarms   │
│  monitoring      │                │  Weekly fairness reports        │
│                  │                │  Quarterly bias audits          │
└──────────────────┴────────────────┴─────────────────────────────────┘

What I Learned Building This

Five things that changed how I think about AI governance:

1. Vendor products do not transfer compliance obligations.

FinNova uses Feature space for fraud detection and HireVue for recruitment. Under the EU AI Act, FinNova as the deployer retains obligations regardless. The vendor risk programmed needs to include AI-specific conformity requirements.

2. HR screening is the most commonly missed HIGH RISK category.

Everyone knows credit scoring is regulated. Almost nobody realizes CV screening is explicitly in Annex III. If you have an HR screening tool, check your bias audit status today.

3. An advisory system with full human review can be minimal risk even in a high-stakes domain.

RegWatch AI monitors financial regulations — clearly high-stakes. But it’s minimal risk because it only flags, never decides. The risk is in how humans use the output. This is proportionality in action.

4. SHAP drift is a regulatory metric, not just a technical one.

If a credit scoring model’s feature weights shift significantly, it may no longer be making decisions on the grounds stated in its conformity assessment. Under Article 61, that is a regulatory event.

5. AI governance and cloud security are not separate disciplines.

The EU AI Act’s technical requirements — logging (Art. 12), human oversight (Art. 14), cybersecurity (Art. 15), post-market monitoring (Art. 61) — all require AWS implementation. The SOC analyst is the person implementing those controls. Understanding the regulatory why makes you dramatically more effective at the technical how.

FinNova Technologies is a fictional company created for this case study. All AWS account IDs, ARNs, and resource names are illustrative.