For most organisations the question about AI has been what it can do. That question is being replaced by a harder one. Could you explain, to someone with the power to ask, how you are using it, how it reaches a decision, and what you considered before you let it?
Who will ask
The list is longer than it was, and it is not only regulators.
A financial services firm in the UK already has a duty to deliver good outcomes for retail customers and to be able to evidence that it has. The Financial Conduct Authority's Consumer Duty is not written in terms of models, but a model that prices, declines or prioritises a customer is a decision about that customer, and the duty applies to the outcome.
Data protection law gives people rights around decisions made about them automatically, and the Information Commissioner's Office has published guidance on explaining decisions made with AI. Organisations in scope of the EU AI Act carry obligations that depend on how a use is classified. Sector regulators in banking and in health have set out their expectations for models in their own terms.
Then there are the people who ask without a statute behind them. An auditor who wants to see the process and whether it was followed. A customer who was refused and wants to know why. A journalist. An acquirer doing due diligence. And a board, which now carries direct accountability for how the organisation governs data and AI, and will want to know before any of the others do.
What "defend" means
It does not mean proving the model was right. It means being able to show four things.
Which decisions AI touches, and who owns each one. Not a list of projects. A list of decisions, with a named person against each.
Why each use was chosen, and what was considered at the time. The customers it affects. Whether anyone could be treated unfairly. What data it uses and whether the organisation has the rights to use it that way. Which duties and rules apply.
What controls are in place, and whether anyone has checked them lately. A control that was designed and never reviewed is a drawing.
What it actually did. Whether the outcome matched the intention, and the evidence for that.
A good intention is not a defence. Most organisations that get this wrong did consider their customers. They talked about fairness in the workshop. The problem is that nobody wrote it down in a place that survived, so when the question came, the honest answer was "I think so".
Why the honest answer is usually "I think so"
The reasons are familiar, because they are the same reasons data and AI programmes struggle in general.
The decision to proceed was made in a meeting and the reason sat in a thread. The risks were captured in a spreadsheet that holds the risks but cannot say which use case introduced one or what the position was on the day the board signed it off. The person who understood the trade-off has moved on. This is the condition described in A strategy problem or a memory problem?, and defensibility is where it becomes expensive.
The business case that got the use approved may have been the thinnest document in the chain, which is the pattern in Most AI business cases die in committee. The ones that survive are the ones that carried evidence, and that evidence is exactly what a regulator will ask to see later.
And there is a quieter reason. When a model drafts the classification, the summary or the risk, it is easy to let its output stand as the decision. Judgement is becoming transferable looks at what that does to an organisation. For defensibility the rule is simple: a model may propose, a named person decides, and the record must show which is which.
What a defensible position looks like
It is less than people fear and more than most have. In practice it is a record with six properties.
- Every use of AI sits on one register with a named owner.
- The reason for proceeding is written down at the time, beside the decision, with the person who took it.
- Every risk is linked to the use case or data asset that introduced it, carries the rule or duty it rests on, and has a review date that somebody is told about.
- High and critical risks carry controls, or the register says which do not.
- On a stated date, a named person signs a snapshot of the position, and it cannot be edited afterwards.
- The process statement says what it does not cover. A statement that only lists what went well is not evidence of anything.
None of this needs the model to be explainable in the technical sense. It needs the organisation to be explainable.
This is not a compliance project
The temptation is to hand this to the risk function and call it governance. That produces a parallel record that nobody running the programme reads, and it goes stale.
The record that defends the organisation is the same record that shows whether the programme is working. The use case that a regulator asks about is the use case the board asked about at its last meeting, when it wanted to know whether the investment was paying off. Keeping one record for both is the difference between oversight and being briefed, and it is the premise of Is your AI strategy working, or is your organisation just busy?. The AI strategy framework sets out where the decisions and the evidence belong in a programme.
Where this record is kept
Assettia is the data and AI programme record: one place where an organisation keeps what its programme owns, what it has decided, and what it has proved. Risks are linked to the use case that introduced them, carry regulatory reference points approved by a person from official sources, and are attested on a stated date by a named leader. The governance process statement it produces is the document a regulator or an auditor would be given, including what the process does not cover.