Skip to content
1961 Digital TransformX
العربية

Service

Nobody has said who is answerable for a wrong answer.

Most AI pilots do not fail on accuracy. They fail because no one was named as answerable when the output is wrong, so nothing can be approved for real work. We settle the accountability first, then the tooling.

Book a consultationAll services

You will recognise this

  • Staff are pasting customer records into public chat tools and nobody has told them to stop.

  • A pilot gave good demonstrations six months ago and has not reached one live process since.

  • Your auditor asked how a figure was produced and nobody could reconstruct how the model reached it.

  • A vendor switched on AI features inside a system you already run and nobody reviewed them.

  • Two departments are buying different AI tools on separate cards, and no register lists either.

How the work runs

  1. Inventory what is running

    We list every model, feature and tool actually in use, including the ones bought on a personal card and the AI quietly switched on inside software you already own. The register names the owner, the data it sees and the decision it touches. Most of it had never been written down.

  2. Classify by consequence

    We sort each use by what a wrong answer costs. A drafted email is not a credit decision, and a maintenance suggestion is not a diagnosis. The classification decides how much review each use carries. Anything that cannot survive a wrong answer is refused, and the refusal is written down.

  3. Name the human reviewer

    Every use with real consequence gets a named role that checks the output before it acts, an escalation path for when the reviewer disagrees, and a rule for who covers the review during leave. A control that depends on one enthusiastic person is not a control.

  4. Set logging and retention

    We decide what is recorded for each use: the input, the model version, the reviewer, the decision and the date. Then how long it is kept and who may read it back. This is what an auditor asks for, and none of it can be reconstructed after the fact.

  5. Rehearse and review

    We run the framework against real incidents: a wrong output that reached a customer, a supplier changing a model without notice, a reviewer who approved everything for a month. Whatever survives becomes the standing review, dated, with an owner and a next review date attached.

What you are handed

  • Register of every AI use, its owner and data scope
  • Written AI use policy in Arabic and English
  • Risk classification stating the review level per use
  • Logging and retention standard for each classification
  • Vendor and model assessment questionnaire
  • Board-ready control report mapped to ISO/IEC 42001

Why the pilot never went live

The demonstration worked. The model summarised the contracts, drafted the replies and flagged the odd invoice. Then someone asked the only question that decides anything: when it is wrong, who carries it. Nobody had an answer, so the pilot stayed a pilot, and it is still sitting in a slide deck a year later. Accountability is not a document written after the technology works. It is what determines whether the technology is allowed to work at all. Name the role that reviews, the escalation when the reviewer disagrees, and the record that proves the review happened, and the pilot finally has somewhere to go.

The AI you did not buy on purpose

Some of the AI in your company was never a decision. It arrived in an update to software you already run: a suggested account code, a forecast in the sales module, a summary in the mailbox, a filter that quietly ranks suppliers. Your staff bought the rest on a personal card because it made their week shorter, and they were right to want that. None of it appears in a register. The first output of this work is usually the surprise itself: a list of a dozen models touching company data that nobody approved, several of them sending that data outside the country every day.

Written to survive a change of staff

A framework that only works while its author is in the building is a story, not a control. So everything is written to be executed by whoever holds the role next. The policy names roles rather than individuals, each control states what evidence it produces, and every use carries a review date that arrives whether anyone remembers it or not. We align the structure to ISO/IEC 42001 because it gives your board and your auditor a vocabulary they already recognise. Alignment is what we do. We do not claim certification to that standard, and you should ask any firm that does to show you the certificate.

Questions we get asked

Is this premature when we barely use AI yet?
It is cheaper now. A register of four tools takes days. The same register after two years of departmental purchases takes weeks and produces arguments about who authorised what. The policy also prevents the expensive mistake happening while you decide, which is staff pasting customer records into public tools. Most of the work is deciding what you will not allow, and that does not depend on scale.
Will this stop our teams using AI at all?
The opposite happens more often. People hold back because nobody has told them what is permitted, so the useful low-risk uses never start. Naming the harmless categories in writing releases them. What the framework blocks is narrow: decisions where a wrong answer reaches a customer, a regulator or a payment with no human in between. Those are refused explicitly rather than by nervous silence.
Can you certify us to ISO/IEC 42001?
No, and no consultancy can. Certification is issued by an accredited certification body after an audit, and that auditor must be independent of whoever built the system. What we do is align your policies, controls and evidence to the structure of the standard so an audit finds them where it expects to. If you intend to certify, say so early: it changes what evidence we keep from day one.
Who is liable when the model gets it wrong?
Your company is, in front of your customer and your regulator, whatever the supplier terms say. That is why the framework starts with a named internal reviewer rather than with vendor selection. The contract matters second, and we read it: what the supplier logs, whether they train on your data, and what notice they give before changing a model underneath you.
What ongoing work does this leave us with?
A quarterly review, a register somebody updates when a tool is added, and a reviewer's time on the uses that carry consequence. It is deliberately small, because a control regime heavier than the risk it covers gets abandoned in the first busy month. If a control cannot be run by an ordinary person in an ordinary week, we remove it and record why.

Often bought together

Tell us what is not working

Send one line about what is going wrong. On the first call we will tell you whether it is a system problem, a process problem or a governance problem — and which one to fix first. That call is free and it is not a sales meeting.

Book a consultation