Accountable, Traceable, Auditable

AI and HSE Management: The Good, the Bad and the Accountable — Part 7 of 8

Summary

  • Three questions provide a practical way to assess the governance of AI-assisted compliance decisions: who is accountable, can you trace how the decision was made, and can someone independent verify that the controls worked?

  • “Human in the loop” offers little assurance unless that human has the competence, time and authority to overrule the tool.

  • Asking a second AI tool to check the first does not, by itself, create independent verification. That comes from checking grounded in authoritative sources, competent judgement and actual site conditions.

  • AI governance fits within the ISO management systems most organisations already run, but ISO/IEC 42001 also brings AI-specific requirements that need deliberate attention.


The last two posts established where accountability sits and what governance expectations are emerging. This post is about what good governance looks like in practice.

In my previous series I set out a seven-step workflow for responsible AI-assisted compliance: defined use cases, validated sources, traceability, recorded uncertainty, named accountability, review records and periodic audit of the AI workflow itself. That workflow remains the foundation.

This post looks at what the earlier parts of this series add to it. If AI can erode judgement, collapse the independence of our checks and move our data beyond our control, then a workflow alone is not enough. The people and the barriers inside it have to be governed too.

Three questions provide a practical way to assess whether that governance is working. They are not legal tests prescribed by any regulator. But they are the questions a regulator, auditor or court is likely to be asking, in one form or another, after something goes wrong.

Test one: who is accountable?

Every AI-assisted compliance decision should have a named decision owner: a person whose judgement the decision reflects. That is distinct from ownership of the AI-enabled process itself, which should also be assigned. Accountability may sit legitimately with supervisors, managers and the organisation as well, but someone must own each decision.

Naming the owner is the easy part. The harder part is making sure that person can actually do the job. “Human in the loop” sounds reassuring, but it is only an effective safeguard if the human has three things:

  • the competence to recognise when the AI is wrong;
  • the time to review the output properly rather than wave it through;

  • the authority to reject it, even when it is well written and the deadline is close.

Without all three, human oversight may offer little assurance. It may put a name on the approval record without providing an effective safeguard.

This is where the fluency trap described in Part 2 becomes a governance issue. If competence is quietly eroding, the named owner may become less able to challenge the AI each year, while the paperwork continues to show the same sign-off. So competence has to be managed as a control in its own right:

  • assess people on their reasoning, not only on the completeness of their documents;
  • preserve direct human observation, site verification and investigative judgement: AI may support these activities, through transcription, translation or organising information, but should not replace the competent person’s own assessment of the evidence;

  • decide which tasks junior staff must learn to do themselves before AI is allowed to help;

  • recognise that reviewing AI output well is a skill, and train for it.

Test two: can you trace how the decision was made?

Traceability means the organisation can reconstruct the path from source information, through the AI’s contribution, to the approved decision. In practice, that means being able to answer:

  • Which legal requirement or technical standard does this rely on, and where is it in the primary source?
  • Which version of that requirement was the decision based on?

  • Which AI tool and available model or release identifier were used, and when was the output generated?

  • What did the AI produce, and what material changes did the reviewer make?
  • What assumptions or limitations were recorded?

  • Who approved the final decision, and when? 

Traceability also has a dimension that Part 3 of this series made clear: independence. It is not enough to show that four people reviewed a document. The organisation should be able to show whether those reviews were genuinely independent of each other.

Asking another AI tool to check the first may provide useful supplementary checking, but it does not, by itself, establish independent verification. Different systems may reproduce the same assumptions, draw on similar information or overlook the same hazard. Equally, an organisationally independent reviewer provides little assurance if they simply endorse the output without examining its assumptions and supporting evidence.

For high-consequence HSE decisions, at least one verification step should be grounded independently in authoritative legal or technical requirements, competent professional judgement and, where relevant, actual site conditions. The question is not how many reviews took place, but whether the verification process was capable of finding an error in the original assessment.

On major GCC projects, these controls must also work across organisational boundaries. An AI-generated risk assessment prepared by a subcontractor, reviewed by the main contractor and accepted by the client may carry several signatures, but those signatures do not necessarily show that the underlying hazards were independently verified.

Test three: can someone independent verify it?

Auditable is more than documented. It means an independent reviewer can examine reliable records and confirm that the controls actually operated.

That distinction matters. A register of AI tools is useful evidence, but its existence does not prove the tools were appropriate, tested or properly controlled. A signed review record does not prove the review was effective.

For AI-assisted compliance, auditable evidence typically includes:

  • an AI inventory: each AI use case, not just each tool, with its purpose, responsible owner, the data it handles and its risk rating;
  • review records showing what was checked, what was challenged or rejected, and against which sources;

  • testing records: periodic testing of AI outputs against independently verified cases, including known errors, difficult or ambiguous requirements and representative real-world scenarios, repeated after material changes to the tool, its data sources or how it is used;

  • data controls: the approved tools list, the rules on what information may go into which tool, and the AI-use terms in consultant and contractor agreements, as discussed in Part 4.

The depth of governance should be proportionate to risk. An AI tool used to improve the grammar of a training presentation does not warrant the same assessment, testing and oversight as one supporting process-safety decisions.

The UAE Central Bank’s February 2026 guidance provides a useful example of a documented supervisory expectation for an AI inventory, including model name, purpose and risk rating. That guidance addresses licensed financial institutions; it does not create a general inventory obligation for other GCC businesses.

None of this is unusual. It is the same discipline organisations already apply to calibrating instruments or verifying contractor competence. A process that cannot be evidenced is difficult to defend or verify.

What this looks like in practice

Consider an industrial facility in Abu Dhabi using AI to help maintain its environmental legal register and the compliance assessments that depend on it.

Accountable. A designated environmental compliance manager owns the AI-assisted workflow. Competent staff verify the applicable legal requirements and have the authority to reject incorrect or incomplete outputs.

Traceable. Every compliance obligation can be linked to its primary legal or permit source. The organisation records the applicable version, the AI-generated interpretation, any material corrections, and the person who approved the final compliance determination.

Auditable. An internal auditor, independent of the AI-assisted compliance process, samples obligations and traces each one from its legal or permit source, through the compliance assessment, to evidence that the requirement is being met. The audit also performs an independent completeness check against the applicable legislation and permit conditions, to find obligations the AI-assisted process may have missed.

The audit therefore tests two different things: whether the obligations on the register are correctly interpreted and implemented, and whether material requirements are missing from it altogether.

If the AI tool overlooks a permit condition, these controls improve the prospect of detecting and correcting the omission before a deadline is missed or harm occurs. Periodic audit provides additional assurance, but does not replace verification before reliance.

The objective is not to prove that AI never makes mistakes. It is to demonstrate, through testing and independent assurance, that the organisation’s controls can identify and manage material errors.

It fits what you already run

Leaders sometimes worry that AI governance means another management system. It does not need to.

ISO/IEC 42001, the international standard for AI management systems, uses the same harmonised structure as ISO 9001, ISO 14001 and ISO 45001. Organisations with an established integrated management system can therefore build AI governance into their existing arrangements for risk management, competence, operational control, internal audit and management review.

But the standard also contains AI-specific requirements and controls, such as AI impact assessment and controls over the AI system lifecycle, that need deliberate attention. Integration should not mean simply adding AI to an existing risk register or audit checklist.

Certification is not essential to benefit from the framework. The value comes from implementing appropriate controls, assigning responsibilities and demonstrating that they work.

A practical starting point

Organisations starting from nothing can begin with six practical steps:

  1. Find out what is already in use. Build the AI inventory, including the tools nobody approved.
  2. Set approval limits. Decide which AI uses are permitted, which need additional controls and approval, and which are unsuitable without independent technical or site-specific verification. AI may be fine for drafting training material, but needs far stronger safeguards when it supports lifting plans, energy isolation, emergency procedures or regulatory compliance determinations.
  3. Name the owners. For each high-consequence use, identify who is accountable and check they have the competence, time and authority to fulfil that role.
  4. Protect independence. For decisions that could cause serious harm, require at least one verification step that does not rely on the original AI output or its untested assumptions. Verification should use authoritative legal or technical sources, competent professional judgement and, where relevant, actual site conditions.
  5. Set the data rules. Decide which information may go into which tools, and extend those rules to consultants and contractors.
  6. Keep the evidence, test it, and act on failures. Record reviews, test the tools periodically, and include AI in internal audits and management review. Define when a material error requires the affected use to be suspended, previous outputs to be reviewed, corrective action to be taken and the process to be revalidated before reuse.

The question for leaders

If a regulator, client or auditor asked tomorrow for your AI inventory and the evidence behind one AI-assisted compliance decision, could you produce them, and would they show that the controls actually worked?

We will work through these questions in the webinar.

From principles to practice

The final post in this series looks at how organisations are already putting these controls in place: what structures they use, what they have published, and why the ones furthest ahead built their controls before anyone asked them to.


Why Redlog Is Building for This Future

At Redlog, we are building compliance intelligence tools on the principles set out in my previous series: curated and expert-validated regulatory content, jurisdiction-specific coverage, source traceability, applicability-aware outputs, and an expert-in-the-loop model that keeps professional accountability where it belongs.

This series adds a further principle. AI should strengthen the professional’s judgement, not stand in for it. Tools that show their sources and flag their uncertainty prompt the professional to check, challenge and decide. That keeps them in the left-hand column.

We are publishing this series because the conversation about AI and accountability in HSE should happen inside the profession. It should be shaped by people who understand regulatory compliance, duty of care, operational risk and the consequences of getting this work wrong.

AI will change HSE practice. That is no longer the question. The question is whether the profession will shape that change with judgement, governance and accountability, or allow it to be shaped elsewhere.

If that is how you think AI should work in HSE compliance, it is the conversation we want to have, starting with our webinar.

This is Part 7 of AI and HSE Management: The Good, the Bad and the Accountable. The previous series, AI and the HSSE Profession: What’s Actually Changing, and all of our prior blog posts are available at www.redlogenv.com/blog.

Webinar – Join us on November 16, 10:00 AM CET/ 11:00 AM UTC+3

Webinar: AI, Accountability and HSE Compliance in MENA — What Every Business Leader Needs to Know

Join us for a discussion with our experts to learn more about where liability sits when AI-assisted compliance work goes wrong, what regulators are starting to expect, and what good governance looks like in practice, and more. Register here

Randall D. Shaw, Ph.D.
Latest posts by Randall D. Shaw, Ph.D. (see all)
Posted in AI, Environment, GCC, General, HSE, HSE Management, Laws and Regulations, Middle East, Regulatory Compliance, Security, Worker Safety and tagged , , , , , , , , , , , .

Leave a Reply

Your email address will not be published. Required fields are marked *