Skip to content
Moralto.AIMoralto.AI
Menu

RightTime Governance™

The right governance. At the right time.

RightTime Governance™ connects oversight to the decisions in each AI use case, with review and evidence proportionate to the context.

Curved pale stone architecture against a teal sky

The problem

Governance applied at the wrong moment is not proportionate.

Most governance does not fail because it is missing. It fails because it is applied at the wrong moment, to the wrong things or at the wrong level of detail. A policy may be approved long before a use case reaches an operational decision. A review may ask for information that does not change the outcome. An annual meeting may look orderly while models, suppliers, data and users have already moved on.

A proportionate AI governance framework makes the important differences visible. It asks what decision is being made, who may be affected, how much control the organisation has and what could happen if the assumptions are wrong. The answer determines the review, authority and evidence needed. Lower-impact uses should not carry the same burden as a system influencing a customer outcome, employment decision or safety-critical process.

RightTime Governance™

What RightTime Governance™ is

RightTime Governance™ is Moralto.AI’s method for connecting oversight to the specific decisions in each AI use case, with review and evidence proportionate to the context.

It keeps organisation-wide policy, accountability and control requirements as the foundation, then brings them into the work at the point they can inform a useful decision. That might be deciding whether an internal assistant can use a new information source, whether a supplier change needs a fresh assessment, or whether a customer-facing tool can move from pilot to operation.

The approach is built around responsible speed. Governance should help AI move faster because people know what is expected, who can decide and what needs to be evidenced. Control is part of decision-making from the start, rather than an activity added after delivery has created a problem.

Working principles

The principles behind the framework

Start with the decision, not the document

Begin with the decision people need to make and the outcome the use case supports. The policy, assessment and evidence then have a clear purpose instead of becoming a detached set of documents.

Name the owner for every use case

A use case needs a named accountable owner with enough authority to accept conditions, respond to change and stop or alter the use when its assumptions no longer hold. Contributors and reviewers support that owner; they do not obscure accountability.

Match the depth of review to the context

Review should reflect sensitivity, impact, automation, reversibility, scale, supplier dependence and relevant obligations. Proportionate does not mean casual. It means effort is directed to the decisions where uncertainty or harm would matter most.

Keep the evidence with the decision

Record the rationale, conditions, checks and follow-up where the decision is held. A later reviewer should be able to understand what was known, who decided and what was expected without searching across disconnected systems.

Keep assurance current as things change

A decision is not permanent permission. Changes to a model, supplier, data source, user group, purpose or operating environment should provide a reason to check whether the original controls and evidence still make sense.

The lifecycle

A continuous route from first question to useful evidence.

The lifecycle is continuous, not an annual cycle. A use case can move forward, pause, change direction or stop, with each transition making the next decision easier to understand.

01

Intake and identification

The first task is to find AI where it actually exists. That includes tools bought from suppliers, features quietly added to existing software, experiments run by delivery teams and models built or configured inside the organisation. Intake captures enough context to distinguish a genuine use case from a general capability: its purpose, users, information, supplier or model, proposed outcome and accountable business area. It should be possible to see whether an existing use is expanding beyond its original purpose, not just whether a form has been completed. This creates a working view across internal knowledge assistants, document summarisation, customer support and less visible uses embedded in ordinary processes. Identification is ongoing because adoption does not wait for a central register to be updated. The register is a view of activity, not a one-time inventory.

02

Triage and proportionate assessment

Triage decides how much oversight a use case needs and why. The assessment considers the sensitivity of information, the people affected, the importance and reversibility of the outcome, the degree of automation, scale, supplier dependencies and legal or contractual requirements. A low-impact drafting aid may need clear purpose, access controls, user guidance and a review date. A tool supporting a customer decision may need deeper testing, specialist input, defined human intervention, monitoring and formal approval. The point is not to assign a label that sits in a register. It is to route the use case to the questions, reviewers and authority that can make a sound decision. A pilot can sit within assessment when it produces useful evidence; it is not a substitute for approval. The assessment should explain its route, not merely its category.

03

Decision and ownership

A governance process should end in an explicit decision, not a collection of comments. The record states what is being approved, paused, changed or declined, the rationale, the conditions that apply, the evidence considered and the named accountable owner. It makes clear who contributed technical, legal, security, data or operational judgement and who has authority to accept the remaining uncertainty. Ownership is active: the accountable person can answer questions, ensure controls are used and decide whether a material change requires another review. Recording the decision at the point of approval preserves the reasoning that is otherwise lost in meetings and email. It also gives delivery teams something they can act on, rather than a general instruction to be careful. The owner remains visible after approval, not only at the gate.

04

Operation and monitoring

Once a use case is live, governance moves into operation. The owner and relevant teams monitor whether the approved purpose, users, data, supplier and controls remain accurate. Monitoring can include incidents, complaints, override rates, quality checks, access changes, supplier notices and evidence that human review is taking place where required. The right signals depend on the context; not every use needs a complex dashboard. What matters is a clear route for recording what has been observed and acting when it changes the decision. Review dates may help, but event-based triggers are just as important. Assurance should fit the organisation’s existing operating rhythm so that oversight is part of service, product, procurement and risk conversations. Useful monitoring is evidence for action, not reporting for its own sake. It should also make emerging concerns visible early.

05

Change and re-assessment

A fresh review is needed when a change could alter the original decision. Triggers may include a new model version, material supplier change, different training or reference data, a new user group, a wider deployment, a new purpose, changed automation or an incident that exposes an untested weakness. The owner should not have to guess whether a change is material. The governance model can define the questions and thresholds that bring a use case back for assessment. Re-assessment starts from the existing record, so the organisation can compare assumptions, controls and evidence rather than repeat discovery from zero. The result may be confirmation, new conditions, a narrower scope, a pause or retirement. Change records should show what prompted the review and what changed in response. This keeps assurance linked to the original rationale.

06

Retirement or replacement

Use cases should have a clear route to closure. Retirement may follow a changed process, an unacceptable residual risk, a supplier ending a service, poor performance or a decision to replace the model. The record should capture when operation stopped, what happened to connected data and access, any outstanding obligations and what evidence needs to be retained. Replacement is not always a simple continuation: a new supplier, purpose or decision context may require a new assessment even when the business outcome looks similar. Closing a use case prevents stale approvals from appearing active and gives the organisation a reliable account of what it has used, changed and learned. A clean retirement record also supports future decisions about similar tools. It means the next team can learn from the closure properly.

The lifecycle is a route through decisions, not a queue of forms. Each stage should leave enough evidence for the next person to understand what happened.

How the framework is applied in practice

Moralto.AI brings senior advisory input to the first decisions: what is already in use, where accountability sits, which controls exist and what needs to change. We work with the functions closest to the use case, then help turn the agreed model into routes that delivery teams and reviewers can use.

Citadel can provide the sustained workspace for that model. It links the use case to its owner, assessment, decision, review activity and supporting evidence. At intake, evidence may be a purpose, data description and supplier detail. At assessment, it may include testing, impact considerations and specialist advice. At approval, it includes the rationale, conditions and authority. During operation, it can hold review results, incidents, changes and follow-up.

This matters when a board, customer or auditor asks a question. The organisation can show not only that a policy existed, but what was decided for the use case, who was accountable, what was known at the time and how the decision has been kept current. That is the practical value of an AI governance framework: a defensible record that supports action.

Questions

Frequently asked questions

Is RightTime Governance™ a product or a method?

It is a method for applying governance to the decisions in an AI use case. Moralto.AI uses the method in consultancy, and Citadel can provide the workspace that supports it over time.

Does it replace our existing risk framework?

No. RightTime Governance™ connects AI-specific questions to the risk, security, legal, procurement and assurance arrangements you already use. It helps those functions see the context and evidence they need without creating a parallel risk system.

How is it different from a standard AI governance framework?

It is designed to make a framework operational. Rather than stopping at principles and policies, it links oversight to a named decision, owner, review route and evidence, with the depth shaped by the consequences of the use case.

How do we know how much oversight is proportionate?

Consider who may be affected, what information is used, how automated the outcome is, how reversible it is, the scale of use, supplier dependencies and applicable obligations. These factors should change the questions, authority and evidence required.

Can it work without software?

Yes. The method can be applied through existing tools if they can hold the necessary context, decisions and evidence. Citadel becomes useful when the volume or pace of change makes a shared governance workspace more practical.

What does your governance need to do next?

Bring us the use case, decision or operating question you are working through.