Assessment

A governed AI assessment.

A structured review of how your organization controls its AI today, across the nine areas below. How we think is public, so you can see the whole picture before we talk.

Foundations

  1. 01

    The control question

    Reframe the adoption decision so governance leads and tooling follows.

    • The useful question is not whether to use AI but whether you can control it. A regulator will ask the second one.
    • Govern first, then scale. When the controls exist before the first pilot, every pilot that follows is born compliant.
    • Retrofitting governance onto a running system costs more and proves less than building it in from the start.
  2. 02

    The regulatory map

    Know which obligations apply to AI in a regulated firm and what each one demands.

    • The EU AI Act's Article 50 transparency duties are in force since 2 August 2026, with high-risk obligations following (Annex III from 2 December 2027, Annex I from 2 August 2028).
    • DORA treats AI vendors and cloud services as ICT third parties; the financial entity must govern that risk and maintain a register of its contractual arrangements with ICT providers.
    • GDPR requires data minimization and purpose limits, and transfers outside the EEA must satisfy Chapter V, which constrains where inference can run.
    • AML and KYC monitoring obligations require traceable, auditable steps, including any AI step in the chain.

Architecture

  1. 03

    The control plane pattern

    Place a gateway in the request path so policy is enforced on every call.

    • A control plane sits between AI and the systems AI uses. It applies whether the caller is a person in a chat assistant or an agent calling tools.
    • You operate the gateway, not the model provider. Policy, logging, and identity stay under your control.
    • Users and agents authenticate to the gateway, never directly to the model. Credentials are short-lived and follow your identity provider.
    • Every request passes a policy check and leaves an audit record before it reaches a model.
  2. 04

    The six requirements

    Turn governance from a slogan into six concrete tests every use case must pass.

    • Transparency: people always know when they are talking to AI.
    • Human oversight: AI assists and suggests, people decide.
    • Traceability: every action is logged and tied to a named person.
    • Least privilege: each use case gets only the data and tools it needs.
    • Cost accountability: spend is capped and attributed, with a hard stop.
    • Data sovereignty: regulated data stays inside your EU cloud boundary.

Controls

  1. 05

    Identity, privilege, and audit

    Drive access from identity and produce a record for every action.

    • Identity provider groups decide which models and tools a use case can reach. Nothing is granted more widely than the group.
    • Tools are scoped per use case. Read-only by default, with sensitive fields masked.
    • Every call is logged with the caller's identity and streamed to your logging and SIEM.
    • Controls live server-side, where no prompt can switch them off.
  2. 06

    Sovereignty and residency

    Keep inference and data inside an EU boundary and prove nothing crosses it.

    • Inference runs in EU regions inside your own cloud account. Data does not leave the boundary.
    • With EU inference as the only upstream, no request reaches a third party by design.
    • Residency is not a claim, it is a configuration you can show. Region locks and account isolation are the evidence.
    • Sovereignty covers logs and telemetry too, not just prompts and completions.

Operating model

  1. 07

    The autonomy ladder

    Match how far AI is trusted to how much evidence a use case has earned.

    • Four rungs: assisted, semi-autonomous, supervised autonomous, and fully autonomous.
    • Assisted and semi-autonomous keep a person in front of anything that commits.
    • A use case moves up one rung only after its controls are proven in production.
    • Full autonomy is reserved for reversible, well-proven paths, not granted by default.
  2. 08

    From controls to evidence

    Map each control back to the obligation it answers so audits are short.

    • A control that produces no record does not help you in an audit. Evidence is the deliverable.
    • Build a requirement to anchor to control map. Each row names a requirement, the regulation behind it, and the control that leaves a record.
    • Ownership is part of the evidence. Risk, Security, Platform, and Architecture each hold a defined piece.
    • Adopt the standard early, so later high-risk use cases inherit it instead of scrambling for it.

Delivery

  1. 09

    Governed delivery

    Keep AI-assisted development inside the same controls as any other code.

    • Govern the two things every application needs: access to data and a route to production.
    • Applications never hold database credentials. They reach data through tools that engineering builds, audits, and owns.
    • The pipeline is the only route to production, with review gates that cannot be bypassed.
    • The governed path is the convenient path, so teams follow it by default rather than working around it.
How it runs

One week, kickoff to readout.

About one week, remote or on site. It is read-only: we review and interview, we do not change anything in your systems.

  1. KickoffHalf a day

    Agree the scope, confirm the Risk, Security, Platform, and Architecture stakeholders, and get read-only access to how AI is used and controlled today.

  2. DiscoveryDay 1 to 2

    Map the current state through structured interviews and a review of your configs and diagrams: how AI is used, what data it touches, where inference runs, how users and agents authenticate, and what is logged.

  3. AnalysisDay 2 to 4

    Score each use case against the nine areas, assign an autonomy tier, and find the gaps. Design the control model and the requirement-to-evidence map for your regulator.

  4. ReadoutDay 5

    Present findings to leadership and your technical teams: what is safe to start, the controls your first use case must satisfy, the ownership split, and a 90-day plan.

What you get

  • A prioritized shortlist of use cases that are safe to start with
  • An autonomy tier and risk assessment for each candidate
  • The control model your first use case must satisfy
  • A requirement to control to evidence map for your regulator
  • Ownership split across Risk, Security, Platform, and Architecture
  • A 90-day plan for a first governed pilot