ADVISORY · AI CONTROL DESIGN

Decide what to build, and the rules it must follow.

Most AI programmes fail on the decision, not the code. AI Economics qualifies the use case, defines the economics, and turns supervisory obligations into rules an engineering team can actually enforce.

USE CASE DECISION CARD

Illustrative

Recommendation: proceed to pilot

Customer operations assistant

DECISION

Framed

ECONOMICS

Modelled

OBLIGATIONS

Mapped

HARD RULES

Derived

The rules leave the workshop as a catalogue your engineering team can enforce, whether you work with us or another vendor.

THE DECISION PROBLEM

The expensive mistakes are made before anyone writes code.

By the time a delivery team is briefed, the decision that determines the outcome has usually already been made informally, without economics and without considering the constraints production will impose.

01

The use case is never qualified

A candidate becomes a project because someone senior liked it, not because its value, owner and data were tested against a standard.

02

Economics arrive after the commitment

Inference cost, human review load and the cost of being wrong are modelled once the budget is already spent, if at all.

03

Obligations stay in policy documents

Supervisory requirements are written for auditors, not for engineers. Nobody translates them into constraints a delivery team can apply.

04

No one owns the decision to stop

Without an agreed gate and a named owner, a weak use case is reshaped indefinitely instead of being stopped and its budget released.

FIRST STEP

Use Case Qualification Workshop

A fixed-scope engagement that turns one candidate use case into a decision leadership can defend before delivery funding is committed.

1

Frame the decision

The problem, the business outcome, the named owner and the data actually available today.

2

Establish the baseline

What the process costs in time, money and quality now, so the improvement can be measured rather than asserted.

3

Map the obligations

Which supervisory and internal requirements bind this use case, and what each one demands of the solution.

4

Estimate and recommend

An initial effort and cost estimate with uncertainty made explicit, and a clear recommendation to proceed, reshape or stop.

You leave with a use case card, success metrics, production constraints, a hard rule catalogue, an initial estimate and a written recommendation. A qualified use case can then move to a working PoC in 3 days on MVP Fabric.

ADVISORY MODULES

Three modules. Separate scopes, separate outcomes.

Each module is bought on its own and produces its own deliverable. There is a decision gate after the third: continue to build, or stop with everything the engagement produced already in your hands.

MODULE 01 · 45 DAYS

Discovery

Which AI use cases in the portfolio deserve investment, and in what order.

  • Use case inventory and qualification
  • Value and cost baseline per candidate
  • Ranked portfolio with a recommended first move

MODULE 02 · 60 DAYS

Framework

The AI-SDLC framework and the catalogue of hard rules your delivery must obey.

  • AI-SDLC operating model end to end
  • Hard rule catalogue derived from your obligations
  • Control points, owners and evidence requirements

MODULE 03 · 45 DAYS

Gap analysis

The distance between how you deliver software today and what the framework requires.

  • Assessment against the agreed framework
  • Prioritised remediation plan with effort
  • Decision gate: build, or stop and keep the work

REGULATORY GROUND

Named obligations, not “regulated enterprises”.

Every obligation below is translated the same way: what it demands, what it means for this use case, and which hard rule it becomes for the engineering team.

KNF

Recommendation D

IT area management and ICT security. The document your architecture standards, change management and documentation are actually audited against.

KNF

Cloud processing

What may be processed where, under which classification and with what exit plan, all settled before a deployment target is chosen.

EU

DORA

ICT risk, third-party dependency and resilience testing obligations that reach any AI component sitting in a critical process.

EU

EU AI Act

Risk classification, human oversight and record-keeping duties, resolved for this use case rather than for the organisation in general.

Also covered where relevant: banking outsourcing requirements, internal model risk policy, cloud policy and the organisation’s own AI policy.

DECISION METHOD

Two instruments behind every recommendation.

BOMM

What matters economically

Separates the part of a process where AI changes the cost structure from the part where it only changes how the work feels. Produces the baseline every later estimate is measured against.

DEAL

When a human must intervene

Defines the points at which an AI decision stops being autonomous: what triggers review, who owns the call, and what evidence the intervention leaves behind.

WHAT YOU KEEP

Everything this engagement produces describes your process, not our tooling.

If you never buy the platform, you keep the framework, the hard rule catalogue and the economics. You can implement them with any vendor or with your own teams. The advisory work stands on its own. That is deliberate: a rule catalogue that only works inside one supplier’s product is not governance, it is lock-in.

NEXT

Rules are only real when something enforces them.

Advisory defines the rules. MVP Fabric is the product that applies them to the engineering work itself, so a coding agent cannot merge code that breaks one. If you want to see the enforcement rather than the framework, start there.