From Security Engineer to AI Governance: How I Built an AI System Inventory Engine

A step-by-step technical walkthrough — with risk pyramids, SIEM rules, incident playbooks, and full EU AI Act classification for a fictional fintech company.

Tools used: Python · JSON · Excel · EU AI Act · NIST AI RMF 1.0 · SIEM Integration GitHub: [github.com/safiniazi/ai-governance-inventory] Time to build: ~15 hours | Difficulty: Intermediate

Why I Built This

Most AI governance articles start with “we need to build trust in AI” and end with a generic framework diagram that helps no one.

This article is different. I’m a Security Engineer. I spend my days looking at alerts, triaging incidents, and investigating anomalies. And I noticed something: the same discipline I apply to network security — inventory, classify, monitor, respond — applies directly to AI governance.

But nobody had built a project that connected both worlds.

So, I built one.

This is a complete walkthrough of an AI system inventory for FinNova Technologies, a fictional fintech firm. I’ll show you:

1. How to build a structured AI inventory from scratch

2. How to classify each system under the EU AI Act

3. How to map controls to the NIST AI RMF

4. How to write SIEM rules and incident playbooks for AI-specific threats

5. How to automate inventory validation with Python

Everything is in the GitHub repo. Let’s go.

Part 1: The Problem Nobody Talks About

Before you can govern AI, you need to know what AI you’re running.

This sounds obvious. It isn’t.

In financial services today, AI tools have proliferated through:

• Individual department procurement decisions
• Proof-of-concept projects that became production systems
• Vendor integrations bundled into software nobody reviewed
• Shadow IT that security never knew about

The result is an AI governance gap that no framework can fix until the inventory exists.

Here’s what FinNova’s AI footprint looks like:

╔══════════════════════════════════════════════════════════════════════╗
║              FINNOVA TECHNOLOGIES — AI SYSTEM LANDSCAPE              ║
╠══════════════════════════════════════════════════════════════════════╣
║                                                                      ║
║   LENDING         PAYMENTS         CUSTOMER SERVICE    MARKETING     ║
║   ┌──────────┐    ┌─────────────┐   ┌─────────────┐   ┌──────────┐   ║
║   │CreditScore│   │FraudGuard   │   │NovaChatBot  │   │Persona   │   ║
║   │AI        │    │Pro          │   │             │   │Target    │   ║
║   │SYS-001   │    │SYS-002      │   │SYS-003      │   │SYS-004   │   ║
║   └──────────┘    └─────────────┘   └─────────────┘   └──────────┘   ║
║                                                                      ║
║   COMPLIANCE                        HR                               ║
║   ┌──────────┐                      ┌─────────────┐                  ║
║   │RegWatch  │                      │HRScreener   │                  ║
║   │AI        │                      │             │                  ║
║   │SYS-005   │                      │SYS-006      │                  ║
║   └──────────┘                      └─────────────┘                  ║
║                                                                      ║
║   Total: 6 systems | 3 HIGH RISK | 1 LIMITED | 2 MINIMAL             ║
╚══════════════════════════════════════════════════════════════════════╝

Each system touches different data, serves different business functions, and carries different risk profiles. The inventory is the foundation. Everything else builds on it.

Part 2: What the Inventory Captures For each system, the inventory records:

┌─────────────────────────────────────────────────────────────────┐
│  INVENTORY FIELDS PER AI SYSTEM                                 │
├─────────────────────────────────────────────────────────────────┤
│  IDENTITY          │ System ID, Name, Business Function         │
│  TECHNICAL         │ AI Type, Vendor, Deployment, Data Sources  │
│  DATA PROFILE      │ Sensitivity, Retention, GDPR Category      │
│  OWNERSHIP         │ Business Owner, Technical Owner, SOC Owner │
│  DECISION LOGIC    │ Automated Decision? Human in the Loop?     │
│  GOVERNANCE        │ EU AI Act Tier, NIST RMF Mapping           │
│  SOC               │ SIEM Rules, Severity, KPIs                 │
│  STATUS            │ Compliance Status, Last Audit, Created Date│
└─────────────────────────────────────────────────────────────────┘

The inventory is stored as both a structured JSON file (machine-readable) and a formatted Excel workbook (human-readable). The JSON enables automation — Python scripts can validate completeness, calculate risk scores, and flag compliance gaps.

Part 3: EU AI Act — The Risk Pyramid

The EU AI Act (Regulation 2024/1689) came into force in 2024. It uses a four-tier risk pyramid:

                    ╔═══════════════════════╗
                    ║    PROHIBITED AI      ║
                    ║  (Unacceptable Risk)  ║
                    ║                       ║
                    ║ • Social scoring      ║
                    ║ • Real-time biometrics║
                    ║   in public spaces    ║
                    ╠═══════════════════════╣
                    ║     HIGH RISK         ║
                    ║   (Annex III List)    ║
                    ║                       ║
                    ║ • Credit scoring      ║
                    ║ • Fraud detection     ║
                    ║ • CV screening        ║
                    ║ • Biometric ID        ║
                    ║ • Law enforcement AI  ║
                    ╠═══════════════════════╣
                    ║    LIMITED RISK       ║
                    ║ (Transparency Only)   ║
                    ║                       ║
                    ║ • Chatbots            ║
                    ║ • Deepfakes           ║
                    ╠═══════════════════════╣
                    ║    MINIMAL RISK       ║
                    ║  (Voluntary CoC)      ║
                    ║                       ║
                    ║ • Spam filters        ║
                    ║ • Recommendation      ║
                    ║   engines             ║
                    ║ • Advisory tools      ║
                    ╚═══════════════════════╝

The key insight: Classification is not subjective. The law lists specific sectors and use cases in Annex III. If your system falls in one of those categories, it is high-risk — full stop. This is where most governance frameworks get vague. The EU AI Act does not.

Part 4: System-by-System Classification

SYS-001: CreditScore AI — HIGH RISK

CLASSIFICATION REASONING
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Legal Basis  : Annex III, §5(b)
               "AI systems intended to be used to evaluate
               the credit worthiness of natural persons"
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Risk Factors :
  [✓] Sector        → Financial services (credit)
  [✓] Impact        → Determines access to essential service
  [✓] Automated     → Fully automated decision (loans)
  [✓] Data          → Special category: financial + profiling
  [✓] Vulnerable    → Can disadvantage protected groups

Obligations  :
  → Risk management system (Art. 9)
  → Data governance (Art. 10)
  → Technical documentation (Art. 11)
  → Record-keeping / logging (Art. 12)
  → Transparency to affected persons (Art. 13)
  → Human oversight (Art. 14)
  → Conformity assessment (Art. 43)
  → Register in EU AI Act database (Art. 71)
  → Post-market monitoring (Art. 61)

Compliance   : ⚠  IN REMEDIATION — conformity assessment pending
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

SYS-002: FraudGuard Pro — HIGH RISK

CLASSIFICATION REASONING
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Legal Basis  : Annex III, §5(b)
               "AI affecting access to financial services"
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
⚠  CRITICAL NOTE: FinNova uses a VENDOR product (Featurespace ARIC).
   Under the EU AI Act, the DEPLOYER retains obligations.
   "We use a vendor" is NOT a compliance strategy.

Risk Factors :
  [✓] Blocks real-time transactions (false positives = harm)
  [✓] Operates in milliseconds — no human pre-approval
  [✓] Adversarial evasion risk (fraud actors adapt)
  [✓] Demographic bias documented in fraud datasets

Key Obligations Beyond Standard High-Risk:
  → Vendor conformity declaration required
  → Contractual obligations with Featurespace
  → False positive monitoring by demographic
  → Human escalation path within 4 hours
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

SYS-003: NovaChatBot — LIMITED RISK

CLASSIFICATION REASONING
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Legal Basis  : Article 50 — Transparency obligations

Why NOT High-Risk?
  [✗] No automated decisions on financial access
  [✗] No Annex III category match
  [✓] Human oversight: agent escalation available
  [✓] Advisory only — never binding

Single Obligation:
  → DISCLOSE that users are talking to an AI
  → Option to request a human agent must exist
  → Cannot impersonate a human

Compliance   : ✅ COMPLIANT — disclosure banner active
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

SYS-004: PersonaTarget — MINIMAL RISK

CLASSIFICATION REASONING
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Legal Basis  : No Annex III match; Recital 48

Why Minimal?
  [✓] Recommends products — does NOT deny them
  [✓] No automated decision on rights/access
  [✓] User can opt out
  [✗] No safety implications

Note: GDPR Art. 22 applies separately for profiling.
      DPO manages this — different regulatory regime.

Obligations  : Voluntary codes of conduct only
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

SYS-005: RegWatch AI — MINIMAL RISK

CLASSIFICATION REASONING
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
The system flags regulatory changes. That's it.
All outputs reviewed by compliance professionals.
No personal data processed. No binding decisions.

Even if the stakes of "missing a regulation" are high,
the SYSTEM is advisory — humans make the final call.
Risk is in the domain. Not in the AI model.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

SYS-006: HRScreener — HIGH RISK ⚠ URGENT

CLASSIFICATION REASONING
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Legal Basis  : Annex III, §4
               "AI for recruitment, CV sorting,
               assessment of job candidates"
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
THIS IS THE ONE MOST ORGANISATIONS MISS.

HR screening tools are EXPLICITLY listed in Annex III.
Employment access is a fundamental right.
A rejected candidate filtered by an algorithm may
never reach a human reviewer.

Documented bias risks:
  ⚠ Gender bias (historically disadvantages women)
  ⚠ Age bias (filters out older candidates)
  ⚠ Ethnicity bias (name-based filtering effects)

Current Status:
  ❌ Bias audit OVERDUE
  ❌ Candidate disclosure not yet implemented
  ❌ HR AI policy pending CHRO signature

Status       : URGENT NON-COMPLIANT
               Must resolve before next hiring cycle
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Part 5: NIST AI RMF — The Four Functions

The NIST AI RMF (2023) tells you how to manage risk across an AI system’s lifecycle. It is not a checklist — it is a cyclical process:

┌─────────────────────────────────────────────────────────────────────┐
│                      NIST AI RMF 1.0                                │
│                                                                     │
│   ┌─────────────┐                                                   │
│   │   GOVERN    │ ──────────────────────────────────────────────┐   │
│   │             │  Policies · Accountability · Culture · Roles  │   │
│   └─────────────┘                                               │   │
│         │                                                       │   │
│         ▼                                                       │   │
│   ┌─────────────┐                                               │   │
│   │    MAP      │  Context · Stakeholders · Risk Identification │   │
│   └─────────────┘                                               │   │
│         │                                                       │   │
│         ▼                                                       │   │
│   ┌─────────────┐                                               │   │
│   │  MEASURE    │  Metrics · KPIs · Fairness · Evaluation       │   │
│   └─────────────┘                                               │   │
│         │                                                       │   │
│         ▼                                                       │   │
│   ┌─────────────┐                                               │   │
│   │   MANAGE    │  Respond · Remediate · Monitor · Incident     │   │
│   └─────────────┘                                               │   │
│         │                                                       │   │
│         └──────────────────────── feeds back to GOVERN ◄────────┘   │
│                                                                     │
│  GOVERN underpins all functions. Risk-reducing is cyclical, not     │
│  linear. Each MANAGE decision informs future GOVERN policy.         │
└─────────────────────────────────────────────────────────────────────┘

Proportionality rule:

Risk Tier     │ GOVERN │ MAP  │ MEASURE │ MANAGE │
──────────────┼────────┼──────┼─────────┼────────┤
HIGH RISK     │  ████  │ ████ │  ████   │  ████  │  All four — fully activated
LIMITED RISK  │  ████  │ ████ │  ██░░   │  ██░░  │  MAP + basic monitoring
MINIMAL RISK  │  ████  │ ██░░ │  ░░░░   │  ░░░░  │  Policy + context only

Applying the same controls to every system is not governance — it’s bureaucracy.

Part 6: Security Engineer Perspective — Monitoring AI Systems

This is where my background adds something that most governance projects miss.

SIEM Rules for AI Systems

╔═════════════════════════════════════════════════════════════════════╗
║                  AI-SPECIFIC SIEM ALERT RULES                       ║
╠══════════╦═════════════════════════════════╦══════════╦═════════════╣
║  Rule ID ║  Alert Description              ║ Severity ║  Response   ║
╠══════════╬═════════════════════════════════╬══════════╬═════════════╣
║  AI-001  ║ CreditScore output drift > 10%  ║  HIGH    ║ Notify ML   ║
║          ║ from 30-day baseline            ║          ║ team;       ║
║          ║                                 ║          ║ trigger     ║
║          ║                                 ║          ║ model review║
╠══════════╬═════════════════════════════════╬══════════╬═════════════╣
║  AI-002  ║ FraudGuard false positive spike ║ CRITICAL ║ Escalate to ║
║          ║ > 1% in 1-hour rolling window   ║          ║ fraud team; ║
║          ║                                 ║          ║ manual mode ║
╠══════════╬═════════════════════════════════╬══════════╬═════════════╣
║  AI-003  ║ NovaChatBot hallucination rate  ║  MEDIUM  ║ 100% human  ║
║          ║ > 5% OR prompt injection        ║          ║ review;     ║
║          ║ attempt detected                ║          ║ notify AI PM║
╠══════════╬═════════════════════════════════╬══════════╬═════════════╣
║  AI-004  ║ PersonaTarget data access       ║  MEDIUM  ║ Investigate;║
║          ║ anomaly — off-hours or unusual  ║          ║ notify DPO  ║
║          ║ volume                          ║          ║ if PII      ║
╠══════════╬═════════════════════════════════╬══════════╬═════════════╣
║  AI-005  ║ RegWatch vendor downtime        ║   LOW    ║ Notify CCO; ║
║          ║ > 4 hours during business hours ║          ║ activate    ║
║          ║                                 ║          ║ manual backup║
╠══════════╬═════════════════════════════════╬══════════╬═════════════╣
║  AI-006  ║ HRScreener rejection rate       ║  HIGH    ║ Suspend     ║
║          ║ > 30% variance by demographic   ║          ║ screening;  ║
║          ║ group from baseline             ║          ║ bias audit  ║
╚══════════╩═════════════════════════════════╩══════════╩═════════════╝

AI Incident Response Playbooks

Playbook 1: Model Poisoning / Data Drift

INCIDENT: CreditScore AI accuracy drops below 93% threshold
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

DETECTION
  CloudWatch alarm triggers → SIEM alert AI-001 fires
  SOC analyst receives PagerDuty notification

STEP 1 — CONTAIN (T+0 to T+15 min)
  □ Isolate model endpoint (AWS SageMaker)
  □ Route all new applications to manual underwriting queue
  □ Preserve all CloudWatch logs (do NOT rotate)
  □ Screenshot current SHAP value distributions

STEP 2 — ASSESS (T+15 to T+60 min)
  □ Compare current output distribution vs 30-day baseline
  □ Check training data pipeline for injection indicators
  □ Review recent model version changes (who deployed what?)
  □ Identify if drift is demographic-specific or global

STEP 3 — NOTIFY (T+30 min)
  □ Notify: Head of Credit Risk (business owner)
  □ Notify: ML Engineering Lead (technical owner)
  □ Notify: CRO (if >500 decisions affected)
  □ Notify: AI Governance Board (if regulatory impact)
  □ Escalate to Legal if customer-facing impact

STEP 4 — REMEDIATE
  □ If data poisoning confirmed:
      → Retrain model on verified clean dataset
      → Validate with holdout test set
      → Third-party bias check before reactivation
  □ If model drift (not attack):
      → Activate scheduled retraining pipeline
      → Adjust feature weights
      → A/B test new model vs baseline

STEP 5 — RESTORE
  □ Gradual rollout: 5% → 25% → 100% traffic
  □ Monitor SHAP distributions in real-time
  □ Confirm false positive/negative rates stable

STEP 6 — POST-INCIDENT
  □ Document in AI incident register
  □ Root cause analysis within 72 hours
  □ Update model card
  □ Notify FCA if material impact on customers
  □ Review and update this playbook

EVIDENCE TO PRESERVE:
  • CloudWatch logs (model endpoints)
  • SHAP value snapshots (before/after)
  • Training data pipeline audit trail
  • Approval records for model version
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Playbook 2: Prompt Injection Attack on NovaChatBot

INCIDENT: Adversarial prompt detected attempting to extract
          customer data or bypass chatbot restrictions
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

DETECTION
  Azure Content Safety API flags injection pattern
  SIEM rule AI-003 fires
  SOC analyst reviews flagged conversation

STEP 1 — IDENTIFY (T+0 to T+10 min)
  □ Retrieve full conversation log from Azure Monitor
  □ Identify prompt pattern (jailbreak / data extraction / impersonation)
  □ Determine if attack succeeded (did chatbot respond with restricted info?)
  □ Check if same pattern appears in other sessions (coordinated attack?)

STEP 2 — CONTAIN
  □ If data was exposed: immediately escalate to CISO
  □ Block source IP/session (if identifiable)
  □ Enable 100% human review for all sessions for 24 hours
  □ Preserve conversation logs with full metadata

STEP 3 — ASSESS IMPACT
  □ Was any customer PII exposed?
  □ Did chatbot provide regulated financial advice?
  □ Was the attack a one-off or systematic?

STEP 4 — NOTIFY
  □ AI Product Manager (technical owner)
  □ DPO — if any personal data exposed (GDPR 72-hour clock starts)
  □ Legal — if financial advice was inadvertently given
  □ FCA — if materially affects customer outcomes

STEP 5 — REMEDIATE
  □ Update system prompt to address exploit vector
  □ Add injection pattern to Content Safety filter
  □ Red team test updated prompt before reactivation
  □ Validate escalation triggers still work correctly

STEP 6 — POST-INCIDENT
  □ Add to prompt injection test library for monthly red teaming
  □ Review and update chatbot scope limitations
  □ Document in AI security incident register
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Playbook 3: Bias Alert on HRScreener

INCIDENT: Disparate impact ratio breaches 0.8 threshold
          for gender dimension on Software Engineer role
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

DETECTION
  SIEM rule AI-006 fires
  Demographic composition dashboard anomaly

STEP 1 — IMMEDIATE ACTION (T+0)
  □ SUSPEND all automated screening for affected role
  □ Route all CVs to manual human review immediately
  □ Do NOT delete any scoring data (evidence preservation)

STEP 2 — QUANTIFY (T+0 to T+2 hours)
  □ Calculate disparate impact ratio across all demographic groups
  □ Identify which feature weights are driving the disparity
  □ Determine how many candidates were affected
  □ Review if affected candidates should be reconsidered

STEP 3 — NOTIFY (T+1 hour)
  □ Head of People & Culture (business owner)
  □ DEI team lead
  □ Legal / Employment counsel
  □ CHRO
  □ Works Council (if applicable)

STEP 4 — REMEDIATE
  □ Conduct full bias audit with DEI team
  □ Obtain vendor (HireVue) bias audit documentation
  □ Retrain or reconfigure model with fairness constraints
  □ Third-party validation before reactivation

STEP 5 — CANDIDATE REMEDIATION
  □ Identify candidates potentially affected
  □ Offer human review to all affected applications
  □ Document remediation actions taken

STEP 6 — POST-INCIDENT
  □ Update HR AI Policy (if not yet signed: escalate NOW)
  □ Notify FCA/ICO if material impact
  □ EU AI Act: document as part of post-market monitoring
  □ Quarterly disparate impact testing — increase to monthly
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Part 7: Python Automation — What the Scripts Do

The repository includes two Python scripts that add technical depth.

 'validate_inventory.py'

Checks every system in the JSON inventory for:

• Missing required fields
• Invalid EU AI Act risk tiers
• Automated decision systems without human oversight (EU AI Act Art. 14 violation)
• High-risk systems with insufficient obligations listed
• Compliance status alerts

Sample output:

=================================================================
  FinNova AI Governance — Inventory Validation Report
=================================================================

  Company      : FinNova Technologies
  Systems      : 6
  Errors       : 0
  Warnings     : 1

  ⚠  WARNINGS:
     • [SYS-006 – HRScreener] ⚠  COMPLIANCE ALERT:
       URGENT NON-COMPLIANT – bias audit overdue

  ✅ All systems passed required field validation.
=================================================================

`risk_calculator.py`

Scores each system on five dimensions (weighted):

SCORING DIMENSIONS
─────────────────────────────────────────────────
  Automated Decision      +3.0  (highest weight)
  Annex III Match         +5.0  (legal trigger)
  Data Sensitivity        +2.5
  Business Impact         +2.0  (complexity proxy)
  Human Oversight         -2.0  (risk reducer)
─────────────────────────────────────────────────

Note: The script uses a simplified quantitative model. The legal classification (EU AI Act) always takes precedence — the Annex III list is law, not a scoring exercise. The script’s value is in surfacing inconsistencies and prompting review.

Part 8: Key Governance Insights

After building this project, here are the five things that surprised me most:

1. Vendor products do not transfer obligations.

FinNova uses Featurespace for fraud detection, HireVue for recruitment, and OpenAI for the chatbot. Under the EU AI Act, FinNova — as the deployer — retains compliance obligations. You cannot outsource governance.

2. The category that most companies miss is HR.

Everyone knows credit scoring is regulated. Almost no one realizes that CV screening tools are explicitly listed in Annex III. If you have an HR screening tool, check your compliance 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 a high-stakes domain. But the system is minimal risk because it only flags, never decides. The risk is in how humans use the output. This is the proportionality principle in action.

4. The NIST RMF is not a checklist — it is a thinking tool.

Mapping CreditScore AI to GOVERN/MAP/MEASURE/MANAGE forced me to ask: who is accountable? What does drift look like? What triggers a rollback? These are questions every AI deployment should answer before going live.

5. Governance and security are not separate.

The SOC owns the monitoring. The SOC is the early warning system for model poisoning, bias drift, and adversarial attacks. AI governance without a security operations perspective is incomplete.

What’s in the GitHub Repository

ai-governance-inventory/
├── README.md
├── data/
│   ├── inventory.json          ← Machine-readable inventory (6 systems)
│   └── classification-matrix.json
├── scripts/
│   ├── validate_inventory.py   ← Completeness + compliance checks
│   └── risk_calculator.py      ← Weighted risk scoring + visual output
├── docs/
│   ├── eu-ai-act-classification.md
│   ├── nist-ai-rmf-mapping.md
│   └── soc-analyst-playbook.md
└── FinNova_AI_Governance_Inventory.xlsx  ← 4-sheet Excel workbook

How to Use This for Your Own Portfolio

1. Fork the repository — customise the company and systems

2. Run the scripts — python scripts/validate_inventory.py

3. Add your own SOC perspective — what would YOU monitor?

4. Extend the risk calculator — add more dimensions

5. Write your own version of this article — your voice, your systems

If you are a Security Engineer looking to move into AI governance, this project demonstrates:

• You understand proportionality (not every AI is high-risk)
• You can anchor classification to specific legal provisions
• You think operationally — alerts, playbooks, KPIs
• You can automate governance tasks with Python
• You understand the difference between framework compliance and genuine risk management

That combination is rare. It separates candidates.

FinNova Technologies is a fictional company created for this case study. All systems, data, and scenarios are illustrative.

GitHub: [github.com/safiniazi/ai-governance-inventory]