AI Governance Accountability and Operating Control

AI Governance Accountability and Operating Control

Building cyber resilience and responsible AI adoption through clear ownership, decision rights and practical safeguards

By Rob Bikoko  |  Consulting Partner – ICT, Crowe Zimbabwe  |  14 October 2026

As we commemorate October as International Cybersecurity Awareness Month, our discussion of cyber resilience must include the artificial intelligence systems entering everyday business work. AI can help people analyse information, detect fraud, draft content, serve customers and automate processes. It can also expose data, produce unreliable or unfair outcomes, and turn an incorrect interpretation into an operational action.

The central question is who owns the outcome when AI influences a decision or acts on an organisation’s behalf. Responsibility remains with people and the organisation. Credible governance therefore gives each use case a named business owner, a defined purpose, limits on data and action, proportionate review, evidence from live operation, and a person empowered to intervene. This article sets out those controls and a practical 90 day route to implementation.

AI governance is now a cyber resilience issue

In my earlier Cybersecurity Awareness Month article, “Building Cyber Resilience in an Era of Rapidly Evolving Threats,” I argued that resilience depends on preparation, governance and people as much as on defensive technology. The same principle applies to AI. Intelligent assistants, predictive analytics, recommendation engines, generative tools, fraud systems and connected agents are moving into core processes. Their benefits in efficiency, service delivery and innovation come with security, privacy, legal, ethical, operational and reputational risks.

An AI assistant that drafts a report for human checking creates a different exposure from an agent that reads records, chooses a next step, updates a system and contacts a third party. In the latter case, an error can become an action and then feed subsequent actions. A final output alone may not reveal how the result arose. Governance must cover the whole workflow: its purpose, data, model and vendor dependencies, connected tools, permissions, checks, escalation path and recovery arrangements.

Cybersecurity awareness should prompt leaders to ask whether AI is appropriate for a task, whose information it uses, who may approve its actions, what will reveal a failure, and how the organisation will contain and correct it. AI governance is the set of policies, structures, processes, standards and controls that makes those answers explicit throughout design, deployment, use, monitoring, change and retirement.

Accountability cannot be delegated to a model

Consider a recruitment tool that rejects a qualified candidate, a credit model that denies a loan, a clinical decision aid that offers an inaccurate recommendation, a generative tool that presents false information, or an agent that authorises an inappropriate transaction. The technology may contribute to each result, but it cannot accept risk, explain a business decision to an affected person, remedy the harm or meet an organisation’s obligations. Management must assign these duties before release.

A central AI committee can set policy and see the portfolio. It cannot substitute for the owner of the customer, finance, legal or operational process where the outcome occurs. The roles below should be documented for each material use case, with decision rights and escalation routes understood by everyone involved.

These roles form a practical operating model: governance sets policy and executive oversight; risk and compliance provide assessment, monitoring and reporting; technology teams build, secure and maintain the system; business teams own adoption, performance and outcomes. Clear collaboration matters more than a diagram of committees.

Approve AI according to the authority it receives

Controls should reflect what the system may do, whose data it handles, the potential effect of error, whether an action can be reversed, and whether a person can inspect it before it takes effect. One route for every application would burden simple assistance while underserving high impact autonomous work.

For example, a payment inquiry assistant might authenticate a requester and retrieve a status while being prohibited from changing bank details or releasing funds. Each additional permission calls for a separate business decision, control design and test. Human involvement should increase with consequence and uncertainty: AI may support analysis and recommendations, but a suitably informed person must retain authority over decisions that require human judgment.

Build the governance framework around real use cases

Policy, inventory and risk classification

A formal AI policy should define objectives, acceptable and prohibited uses, accountability, ethical expectations, security and privacy requirements, and approval routes aligned with enterprise governance. An inventory should record each system’s name and purpose, business and technical owners, vendor, data sources, connected tools, permitted actions, risk classification and degree of autonomy. Without a reliable inventory, hidden or informal use will escape oversight.

Assess each use case before implementation and after material change. Examine security, privacy, regulatory and legal exposure; bias and discrimination; reliability and explainability; operational continuity; and reputational consequences. Prioritise systems that affect customers, employees, regulated information, money or critical operations. Higher risk warrants stronger assurance, closer supervision and narrower permissions.

Approval, change and continuous monitoring

An approval is meaningful only while the assessed design remains true. A new model, prompt, data source, vendor service, tool connection, action permission or recipient can change exposure even when the product name stays the same. Document, test, review, approve and monitor material changes. Define the triggers that require reassessment rather than relying on a one time sign off.

During operation, monitor accuracy, service performance, model drift, unusual behaviour, exceptions, security events and impacts on people and business outcomes. Retain enough history to reconstruct a significant case: the request, relevant sources and tool calls, checks, decision, action, exception and human intervention. Protect the logs and apply appropriate privacy and retention rules. The aim is to explain and correct a failure, not to collect every possible trace indefinitely.

Put operating controls behind the policy

Only authorised users and services should reach AI systems and their data. Authentication, role based access, privileged access management and segregation of duties should extend to agents and their connected tools. Credentials and permissions should be limited to the approved task. Security and change controls should cover models, prompts, configurations, integrations and updates, with recovery arrangements for failures.

AI also creates distinctive cyber exposures. Sensitive information may leak through a prompt or output; an attacker may use prompt injection to redirect an agent; malicious or inaccurate source content may manipulate a model’s response; and a vendor or connected service may introduce supply chain risk. Data boundaries, validation of external content, restricted tool actions, monitoring and incident response should address these pathways within the broader cybersecurity programme.

Human override must be real. Define who receives an alert, what event triggers review, the response time, and who can pause, override or shut down the workflow. Test these controls in a pilot, including misleading inputs, unavailable systems, incorrect intermediate results, repeated loops and attempts to act beyond approved scope. A dashboard without an assigned person and intervention authority provides little assurance.

Prepare people to supervise and challenge AI

Human in the loop oversight is effective only when reviewers have time, evidence, competence and authority. A reviewer should recognise unsupported conclusions and request source evidence; an operations supervisor should detect repeated failures or out of scope actions; and the process owner should weigh speed against corrections, oversight effort and customer impact. Train staff for these distinct roles, not simply in generic AI awareness.

The business case should include verification, exception handling and incident costs. A tool that drafts faster but shifts a large burden to reviewers may deliver less value than task volume implies. Track completed outcomes, corrections, review effort, incidents and user impacts alongside throughput. As with cyber resilience more broadly, exercises, executive simulations and a culture of speaking up help people act decisively when technology behaves unexpectedly.

Questions for boards and executive teams

Leadership should ask the following questions regularly, and expect evidence rather than a policy statement alone:

  • Which AI systems and connected agents are in use, and who owns each business process and its outcome?
  • What data, tools, recipients and actions are permitted, and how is misuse or unauthorised access prevented?
  • How were security, privacy, legal, bias, reliability and operational risks assessed and accepted?
  • Can an affected decision be explained and reviewed, and can a person intervene before or after an action?
  • What monitoring reveals drift, error, abnormal behaviour or an incident, and who responds within what time?
  • Can we stop the system, recover the process, and demonstrate compliance with applicable obligations?

Unclear answers identify governance work that should be completed before granting more authority to a system.

A practical 90 day starting point

Days 1 to 30  Establish visibility and ownership

Identify AI use cases, informal tools and connected agents. Name business and technical owners; map data boundaries, vendor dependencies and action permissions; assess initial risk; and agree governance principles. Give early attention to use cases involving people, regulated data, money and operational systems.

Days 31 to 60  Define controls and test failure scenarios

Develop policy, standards, classification and approval criteria. Select representative workflows and assign exception routes, logs, supervision and stop conditions. Test ordinary use and credible failures, including misleading input, unavailable services, incorrect intermediate outputs, privacy exposure and attempts to exceed permissions.

Days 61 to 90  Release in stages and learn from operation

Launch within narrow approved limits, with a named supervisor and a scheduled review of real cases. Train relevant staff, report outcomes and incidents, adjust thresholds and document changes. Expand authority only when the business owner can show acceptable performance, effective human intervention and a clear route to recovery.

Conclusion

International Cybersecurity Awareness Month reminds us that cyber resilience is a shared business responsibility. The adoption of AI makes this responsibility more concrete: leaders must know what a system is allowed to do, protect the information it touches, monitor what it actually does, and empower people to correct or stop it. Governance enables responsible innovation by placing decisions and controls where the risk occurs.

The question for every organisation is straightforward: if an AI system makes a wrong decision or takes an unauthorised step tomorrow, who will know, who can stop it, and who must put the outcome right? If those answers are unclear, there is more governance work to do before the system receives further authority.

 

Facebook
Twitter
LinkedIn
WhatsApp
Email
Skype
Pinterest