RichardHam.co.uk Blog

Tag: governance

  • EU AI Act Compliance: Governance Frameworks in Practice

    EU AI Act: My Clients Were Ready. Most Weren’t.
    Published: November 10, 2025 (retrospective)

    EU AI Act enforcement began in earnest in late 2025. While many businesses scrambled, my clients had zero compliance findings across seven audits. The governance habits built into SentinelForge since 2024—audit trails, human gates, scoped permissions—turned out to be exactly what regulators wanted to see.

    Framework Coverage

    Framework Status Coverage Area
    EU AI Act ✅ Complete High-risk AI systems
    NIST AI RMF ✅ Complete Full stack governance
    ISO 42001 80% Audit-ready
    OECD AI Principles ✅ Complete Transparency + accountability

    What Auditors Actually Look For

    1. Audit trail completeness — every AI decision logged with timestamp and rationale
    2. Human oversight documentation — evidence that humans reviewed high-risk outputs
    3. Data governance — proof that personal data wasn’t used to train models without consent

    SentinelForge’s GitHub-gated architecture satisfied all three out of the box. The logs were already there.

    The Lesson

    Compliance isn’t a bolt-on. The businesses that struggled in 2025 were those that treated AI governance as a 2025 problem. We started in 2023.

    Need EU AI Act readiness for your AI systems? Book a governance audit.

    Next: HeliOS-Studio—AI startup studio ignites (Feb 2026).

  • What 2024 Taught Me About Turning AI Work Into Infrastructure

    s

    2024 was the year AI stopped feeling like a side experiment and started feeling like part of the working stack.

    The biggest change was not speed. It was structure.

    What changed

    • routine work got easier to delegate
    • review became part of the workflow instead of an afterthought
    • local execution mattered more than hype
    • security thinking moved earlier in the process

    The numbers were useful, but the bigger shift was behavioural. I spent less time wrestling with one-off tasks and more time building repeatable paths.

    What worked

    The pattern that kept showing up was simple:

    1. keep the sensitive bits local when possible
    2. make the outputs reviewable
    3. use the repository as the record of truth

    That combination did more for consistency than any single tool choice.

    What I would change

    If I were doing it again, I would write more of the operating rules earlier. The systems worked better once the guardrails were explicit.

    That is usually how these things go. The tech is rarely the hard part. The hard part is deciding how much freedom the workflow should really have.

  • CrewAI Launch: Building Secure Agent Crews

    s

    When multi-agent tooling matured in late 2024, it solved one problem and exposed another. Coordination got easier. Risk did too.

    A system that can research, draft, test, and propose changes is useful. A system that can do all of that without a clear approval path is a liability.

    The basic shape

    Agent orchestration
-> local inference
-> secret handling
-> human approval

    That setup sounds obvious now. It did not feel obvious at the time.

    The first production uses were straightforward: security reviews, repetitive checks, and content drafting. The output was good enough to save time, but only when the guardrails stayed in place.

    Lessons that stuck

    • Give each agent the minimum access it needs.
    • Log outputs before anything changes state.
    • Test for prompt injection and bad assumptions early.

    Those three habits did more for reliability than any naming convention or framework choice.

    What changed

    The real shift was mental. I stopped thinking about agents as clever helpers and started treating them like junior team members. Useful, yes. Trusted by default, no.

    That distinction matters. A junior teammate can ask questions and escalate. An unchecked automation chain just keeps moving.

    The safest systems are boring in the right ways. They make decisions visible. They make mistakes recoverable. They let a human step in before the wrong thing becomes the permanent thing.

  • Why Zero-Trust Thinking Matters in AI Systems

    Zero-Trust + AI: Digital Transformation Gets Real
    Published: April 10, 2024 (retrospective)

    NIST’s AI Risk Management Framework (early 2024) collided with my Control Tower experiments. For years, I’d preached zero-trust to clients. Now I had to apply it to my own AI stack. Cybersecurity governance wasn’t optional anymore—SentinelForge planning began as a direct response.

    Governance Stack Emerges

    The principle was simple: every AI decision must be logged, auditable, and human-gated. The architecture:

    proxmox-ve
├── ollama          (local inference, no cloud leakage)
├── crewai          (agent orchestration, role-scoped)
├── vaultwarden     (secrets, zero plaintext)
└── github          (human approval gates on all PRs)

    This wasn’t theoretical. A March 2024 client incident—an AI-generated script with a subtle privilege escalation bug—proved every layer was necessary.

    Zero-Trust Applied to AI

    Principle Traditional IT AI Stack Application
    Verify explicitly MFA on every login Signed commits on every AI output
    Least privilege Minimal AD permissions Scoped agent tool access
    Assume breach EDR + SIEM Prompt injection detection

    Lessons

    1. Treat AI agents like privileged users—same controls, same audit trails.
    2. NIST AI RMF is practical, not theoretical; map it to your stack early.
    3. Digital transformation without governance is just technical debt with a faster delivery speed.

    Need a zero-trust AI framework for your business? Let’s talk.

    Next: Control Tower blueprints go live (Jul 2024).

  • M365 Copilot GA: Auditing in the AI Era

    t

    When Microsoft 365 Copilot arrived, the immediate question from clients was not “Can it help?” It was “Is it safe to turn on?”

    My answer was simple: not without a proper permissions review.

    AI does not remove tenant risk. It makes existing risk easier to surface.

    What I kept finding

    Across multiple audits, the same issues kept coming back:

    • over-permissive app consents
    • mailbox forwarding rules that nobody had reviewed in months
    • Intune drift that had crept in quietly

    None of that was exotic. It was just the usual gap between default settings and an actual security posture.

    Why the audit mattered

    The useful part of the process was not the reporting template. It was the discipline.

    I needed a way to check the tenant, explain the findings clearly, and keep the evidence somewhere traceable. That made the audit easier to repeat and a lot harder to hand-wave away.

    The lesson

    If Copilot is going to sit on top of the tenant, the tenant needs to be in decent shape first.

    That means permissions, logging, and a clear view of who can do what. Otherwise the tool just gives people faster access to a system they do not actually understand.

Powered by